ZFS is useful if you don't have any higher-level abstractions for bulk storage. Databases and object storage (including cloud storage) generally provide integr

ZFS is useful if you don't have any higher-level abstractions for bulk storage. Databases and object storage (including cloud storage) generally provide integrity, reliability, and snapshot features at least as well as ZFS. If you need robust posix/samba file servers then ZFS is a good choice. I've never worked on a site with a large fleet on ZFS; it always had its own niche. Maybe a good rule of thumb is that if you've ever needed to track down a missing file, fix file corruption, or have contingency plans for such an event in production then ZFS can help. If the default action is to wipe a host and reinstall if the local filesystem looks fishy then ZFS won't provide many benefits. Btrfs has the advantage of living in the kernel tree (but I use ZFS on Freebsd where the same is true), but still carries an aura of not being quite done. There are several "things seem to work well at version X, and watch out for Y" statements in https://btrfs.wiki.kernel.org/index.php/Incremental_Backup https://btrfs.wiki.kernel.org/index.php/Incremental_Backup for example. This is a year old at least so maybe all bugs and caveats are fixed. How could I be sure? No idea. zfs send and receive just work. Btrfs seems to be the filesystem to use if you can dedicate enough time to testing your specific use case thoroughly and keeping up to date with changes and improvements as opposed to ext4 or ZFS which change relatively infrequently. ZFS enables/tracks new features in the zpool metadata so there's a modicum of forward- and backward-compatibility. To be honest I am even a bit leery of ZFS-on-Linux but even Freebsd is moving there soon. Abandoning a working, trusted codebase is always scary.