Overall solid but BTRFS has the advantage of being Linux native in the way it works. Right now I wouldn’t use btrfs for a critical raid system but it is great for single disks.
Canonical ships ZFS like Nvidia ships proprietary drivers, which seems to work (legally and technically) but it means the development of ZoL is a bit cumbersome and can never be integrated in the kernel development like other filesystems.
Oh dear, I didn’t know that. Thanks for the info. I genuinely wish that people would stop using these pushover licenses. I thought it was like the LGPL, but sadly it isn’t. At least the base remains free though.
As someone who uses btrfs mostly (sometimes ext4, but I don’t really know why…), can someone explain the benefits of ZFS over the previous two I mentioned?
The two biggest benefits are that it’s basically a finished implementation of btrfs (see data corruption in large pools and raid 5 and 6), as well as being able to encrypt and compress at the same time.
Plus, and I don’t know if this is a ZFS-specific thing, being able to group disks into VDevs and not just into one big raid.
Tbf, the one thing I find nice, at least for home users, is the ability to throw JBOD and it makes it all work. Less cumbersome for newcomers. Zfs needs disks of the same size or it will only group disks into a vdev and use the smallest of the disks for capacity.
That said, I run zfs and no btrfs anywhere. Had high hopes for bcachefs but… That’s not going particularly well.
Thanks for the info. Does ZFS allow for easy snapshotting like btrfs? Or like the stuff in the backend that allows you to do things like, say, edit a filename while the file is open?
that should work on all filesystems on linux, shouldn’t it? linux keeps file handles by inode number, not filename. this is also the reason system updates can happen while everything is running, because replacing the open files is possible too, and the processes that opened it earlier keep seeing the old version of it
ZFS: 🙂
I wish the licensing would be Linux compatible
Overall solid but BTRFS has the advantage of being Linux native in the way it works. Right now I wouldn’t use btrfs for a critical raid system but it is great for single disks.
But we have OpenZFS, which is under CDDL (=LGPL). So it’s fine.
Edit: I was wrong, see comment below.
CDDL is not LGPL and is GPL incompatible
How so?
https://www.gnu.org/licenses/license-list.en.html#CDDL
Canonical ships ZFS like Nvidia ships proprietary drivers, which seems to work (legally and technically) but it means the development of ZoL is a bit cumbersome and can never be integrated in the kernel development like other filesystems.
Oh dear, I didn’t know that. Thanks for the info. I genuinely wish that people would stop using these pushover licenses. I thought it was like the LGPL, but sadly it isn’t. At least the base remains free though.
Isn’t OpenZFS compatible though?
As someone who uses btrfs mostly (sometimes ext4, but I don’t really know why…), can someone explain the benefits of ZFS over the previous two I mentioned?
The two biggest benefits are that it’s basically a finished implementation of btrfs (see data corruption in large pools and raid 5 and 6), as well as being able to encrypt and compress at the same time.
Plus, and I don’t know if this is a ZFS-specific thing, being able to group disks into VDevs and not just into one big raid.
Tbf, the one thing I find nice, at least for home users, is the ability to throw JBOD and it makes it all work. Less cumbersome for newcomers. Zfs needs disks of the same size or it will only group disks into a vdev and use the smallest of the disks for capacity.
That said, I run zfs and no btrfs anywhere. Had high hopes for bcachefs but… That’s not going particularly well.
Different tools, different jobs. On my computer I also use btrfs, but on the family archive server ZFS (TrueNAS Scale). Right tool for the right job.
Thanks for the info. Does ZFS allow for easy snapshotting like btrfs? Or like the stuff in the backend that allows you to do things like, say, edit a filename while the file is open?
that should work on all filesystems on linux, shouldn’t it? linux keeps file handles by inode number, not filename. this is also the reason system updates can happen while everything is running, because replacing the open files is possible too, and the processes that opened it earlier keep seeing the old version of it
Snapshots like btrfs, yes. But I think every copy-on-write system can do that. But I don’t know about the rest.
Absolutely
Any Linux filesystem will do that