Unfortunately I don't have much experience with btrfs, however I've found the CLI commands for ZFS to be much more intuitive to use - both in terms of how they'

Unfortunately I don't have much experience with btrfs, however I've found the CLI commands for ZFS to be much more intuitive to use - both in terms of how they're invoked and their output. There's one command for handling storage pools (zpool, https://manpages.debian.org/unstable/zfsutils-linux/zpool.8.en.html https://manpages.debian.org/unstable/zfsutils-linux/zpool.8....), e.g. adding/replacing disks, monitoring I/O utilization, etc. And then there's another command for dealing with ZFS datasets (zfs, https://manpages.debian.org/unstable/zfsutils-linux/zfs.8.en.html https://manpages.debian.org/unstable/zfsutils-linux/zfs.8.en...), e.g. setting properties for datasets (quotas, compression, delegation of privileges to non-root users), managing snapshots. Both CLI commands are scriptable (e.g. -H can be used to suppress human-readable headers and -p turns off "friendly" formatting for numbers) and there are libraries (libzfs, libzpool) which can be used to access their functionality (e.g. for managing snapshots) in your own programs. I don't think I can do ZFS on Linux (or btrfs for that matter) justice in a (short) comment on HN. There's just so much to it (e.g. SSDs as cache/log devices, sending/receiving snapshots over the network, compression, etc.) There are some rough edges, of course. Until a few years ago ZFS on Linux had massive problems with resource management, i.e. it would regularly panic in low-memory situations. These appear to be fixed though - at least I haven't seen any panics in the past two or so years. Due to its license ZFS on Linux will probably never be part of the upstream kernel. We use it on Debian which means we get to compile the ZFS kernel modules on each box when there's a kernel update (with DKMS). Plus there are some pitfalls when using ZFS as your root filesystem (on Debian stretch without systemd services would start before /var/log was mounted). We've had plenty of disk failures which ZFS detected well before SMART did because we run monthly scrubs for our ZFS pools (i.e. basically ZFS verifies its checksums for all the data that's stored in a pool). Recovery is as easy as popping in a new disk and running "zpool replace". Ok, this ended up much longer than I had planned. This has to suffice for now.