I would tentatively disagree with raising the bar and describe it using my favorite MySQL / PostGRES analogy that they have a fundamentally different philosophy but do about the same thing.
For example, if you want to do something software raid-ish, ZFS has the philosophy that should be done at the filesystem layer, not as a virtual device like every other linux filesystem, ever. Its not a new feature to be able to do RAID, but its new to embed RAID into the filesystem layer itself. Linux style virtual RAID devices don't care if you build a FAT32 on top of /dev/md0.
There are other examples of the same philosophy in ZFS. For example everywhere else in linux if you want some manner of "volume manager" you simply use LVM. ZFS has its own interesting little volume manager. Which relates to snapshots.
It's exactly the same with encryption. Every other implementation on linux uses a loop device and your choice of algo. ZFS shoves all that inside the filesystem.
Another philosophical decision is every other linux filesystem doesn't scrub, but only fsck's metadata, so logically ZFS implements the exact opposite.
Although ZFS supporters are technically telling the truth when they run around saying only ZFS can provide software RAID, or only ZFS has a volume manager, and ext2/3/4 does not, its not relevant. I've had LVM and software RAID and all that for many years on existing linux stuff.
One of the few true features ZFS provides is allowing ridiculously big filesystems. Which is cool.
It is mostly a philosophical difference between modularity and monolithic design, with pretty much everything else being modular, and ZFS being extremely monolithic.
In that way I don't think ZFS has prodded any innovation at all in any other filesystems other than maybe BTRS which I haven't been following because my data is too valuable to experiment upon and filesystems aren't my thing. I don't see the iso9660 FS driver adding native volume management, snapshotting, software RAID, and encryption any time soon.
> For example, if you want to do something software raid-ish, ZFS has the philosophy that should be done at the filesystem layer, not as a virtual device like every other linux filesystem, ever.
Not exactly true. RAID and mirroring logically sit at the zpool layer, and therefore anything on top of a given zpool has the zpool's RAID/mirror characteristics. This may be a filesystem, but it could also mean a zvol too. A zvol would be analogous to your /dev/md0 block device in that you could put a FAT32 filesystem on top of a zvol and still benefit from the underlying redundancy, parity, and checksumming features of ZFS.
Addendum: Strictly speaking, redundancy (RAID or mirror) configuration is on a vdev, and a zpool is comprised of one or more vdevs over which data is striped.
ZFS shoves all that inside the filesystem. [...] I've had LVM and software RAID and all that for many years on existing linux stuff.
I suggest you study the design of ZFS and also NetApp's WAFL to understand why they are combining what have traditionally been separate layers into one larger system.
The short version is that this cross-cutting of layers enables substantial optimizations and new features that aren't possible when everything is kept to strict interfaces.
But your conclusion is basically what I wrote, that one design is monolithic and one design is modular.
Yes in theory you could probably come up with a weird pathological scenario where a monolithic design is slower and a modular design is faster. But that usually doesn't happen.
Usually, turning a modular design into a monolithic design for a tiny performance gain turns into an epic disaster/mistake. Maybe the whole ZFS thing will be an exception. Probably not.
Yes in theory you could probably come up with a weird pathological scenario where a monolithic design is slower and a modular design is faster. But that usually doesn't happen. [...] Usually, turning a modular design into a monolithic design for a tiny performance gain turns into an epic disaster/mistake.
Well, think about this. Suppose you're running RAID-1 with two drives, and you've got some filesystem (maybe ext4, but that doesn't matter) running on top of that. You create one huge file, and then a little while later you delete it. And right after that, one of the disks dies, and you replace it.
In this case, your RAID layer doesn't know that most of the data written to the original drive is junk, and that the only really important bits are some inodes and directory entries consuming a few MB near the end of the disk. It has to re-mirror the entire drive from the original to the replacement before they are in-sync again and you are fully protected. Even with modern drives, that leaves a large window of time that you're not protected.
If, on the other hand, your RAID layer has a thicker interface to the filesystem than just a dumb block store, it can just mirror the little bit of metadata, and within seconds you're in sync again and fully protected.
That's just one example. There are many more. Go read the stories about people complaining about RAID-5 and RAID-6 performance.
I don't know much about RAID and other systems, but does anything other than ZFS read data from disk, determine that it was corrupt, go to another disk and get the same data and verify that the hash is good and then automatically fix the corrupt data? That seems like a killer feature to me.
Hmmm. I run NTFS and truecrypt on top of raidz zpool allocations (zvols, virtual block devices) all the time, block storage doled out over iSCSI from my ageing Nexenta box.
I do think you're too quickly dismissing the advantages of the fs being aware of the underlying block storage provider, to the point of being able to grow elastically from common storage rather than preallocate at partition time.
I'd much rather the whole md layer be replaced by zpool even if zfs itself is not used.
For example, if you want to do something software raid-ish, ZFS has the philosophy that should be done at the filesystem layer, not as a virtual device like every other linux filesystem, ever. Its not a new feature to be able to do RAID, but its new to embed RAID into the filesystem layer itself. Linux style virtual RAID devices don't care if you build a FAT32 on top of /dev/md0.
There are other examples of the same philosophy in ZFS. For example everywhere else in linux if you want some manner of "volume manager" you simply use LVM. ZFS has its own interesting little volume manager. Which relates to snapshots.
It's exactly the same with encryption. Every other implementation on linux uses a loop device and your choice of algo. ZFS shoves all that inside the filesystem.
Another philosophical decision is every other linux filesystem doesn't scrub, but only fsck's metadata, so logically ZFS implements the exact opposite.
Although ZFS supporters are technically telling the truth when they run around saying only ZFS can provide software RAID, or only ZFS has a volume manager, and ext2/3/4 does not, its not relevant. I've had LVM and software RAID and all that for many years on existing linux stuff.
One of the few true features ZFS provides is allowing ridiculously big filesystems. Which is cool.
It is mostly a philosophical difference between modularity and monolithic design, with pretty much everything else being modular, and ZFS being extremely monolithic.
In that way I don't think ZFS has prodded any innovation at all in any other filesystems other than maybe BTRS which I haven't been following because my data is too valuable to experiment upon and filesystems aren't my thing. I don't see the iso9660 FS driver adding native volume management, snapshotting, software RAID, and encryption any time soon.