Lots of ZFS users are enthusiasts who heard about that one magic thing that does it all in one tidy box. Whereas usually you would have to known all the minutiae of LVM/mdadm/cryptsetup/nbd and mkfs.whatever to get to the same point. So while ZFS is the nicer-dicer of volume management and filesystems, the latter is your whole chef's knife set. And while you can dice with both, the user groups are not the same. And enthusiasts with the right usecases are very few.
And for the thin-provisioned snapshotted subvolume usecase, btrfs is currently eating ZFS's lunch due to far better Linux integration. Think snapshots at every update, and having a/b boot to get back to a known-working config after an update. So widespread adoption through the distro route is out of the question.
Ubuntu's ZFS-on-root with zsys auto snapshots have been working excellently on my server for 5 years. It automatically takes snapshots on every update and adds entries to grub so rolling back to the last good state is just a reboot away.
> And for the thin-provisioned snapshotted subvolume usecase, btrfs is currently eating ZFS's lunch due to far better Linux integration.
Is this a technical argument? Or is this just more licensing nonsense?
> Think snapshots at every update, and having a/b boot to get back to a known-working config after an update.
I use ZFS and I have snapshots on every update? I have snapshots hourly, daily, weekly and monthly. I have triggered snapshots too, and ad hoc dynamic snapshots too. I wrote about it here: https://kimono-koans.github.io/opinionated-guide/
And for the thin-provisioned snapshotted subvolume usecase, btrfs is currently eating ZFS's lunch due to far better Linux integration. Think snapshots at every update, and having a/b boot to get back to a known-working config after an update. So widespread adoption through the distro route is out of the question.