> From: Dan Ritter [mailto:d...@randomstring.org] > > It doesn't exist. I do not think it would be reasonable to have it exist. > > btrfs RAID1 does not mean the same thing as LVM RAID1 or mdadm RAID1, > and > a flag on a filesystem can't tell you that it's stored on hardware RAID1. > > btrfs compress via LZO has different semantics than zfs compress via LZ4, > and will still be different when btrfs implements LZ4. > > You can't btrfs send | zfs receive.
No matter what filesystem you are using, your application calls file.open() and file.write() and file.read() and file.close(). You can register for inotify notifications. There may or may not be selinux context tags, or ACL's, or posix ownership/permission bits. If you call any of these functions, on filesystems that don't support them, they may throw errors (so you know they failed) or they may silently fail. I certainly know I've seen both noisy and silent failures of these types. When you call file.open(), some filesystems support file handle exclusivity, file locking. When you write a file, some filesystems support distributing notification to the other applications that were interested in that file, or parent directory. The kernel provides an API to the application layer, and the kernel supports various features in each individual filesystem under the hood. If you were an application developer, trying to evaluate whether or not your application is supported on a particular filesystem, you'd start by just looking at wikipedia to get a general understanding of the limitations of that filesystem, and if there wasn't any obvious problem, you'd look to see what filesystem calls you actually use in your application, and check to see if the kernel implements those features on the given filesystem. If you are a filesystem service provider, trying to evaluate whether or not your users' applications could be supported on a *different* filesystem, but you have limited knowledge about the users' application, you'd start by consulting wikipedia to understand the differences between the filesystems, and barring anything obvious, you'd like to set up monitoring, to see what operations their applications perform on the filesystem, and then see if those operations are also supported on the other filesystem. I swear, at least for the evaluation between ext4, xfs, and btrfs, I saw something like this. In my mind, it was directly analogous to cat /proc/cpuinfo to see what features your CPU supports. I have a fairly high degree of confidence, that at least for the above named filesystems, there was a way to query the kernel (or something) to list which features the filesystem is capable of supporting. Man pages tell you things like how to change your UUID, and tweak the number and size of inodes, enable and disable case sensitivity, toggle selinux contexts, etc. They don't tell you which parts of the filesystem layer API are implemented, or to what extent. They don't tell you if file locking will be supported, or inotify. In this particular case, I'm evaluating NFS vs GPFS. I decided a couple of days ago, when it didn't look like I was going to find a systematic way of evaluating filesystem differences in general, that it's best to just focus on the differences between the two specific filesystems I care about in this case. So google and man, specifically for nfs and gpfs, are the way to go this time. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
