I hosted my coding environment on a VPS running FreeBSD and happen to jump between VPS provider quite a bit due to location and pricing. My migration method was simply:

    $ zfs snapshot zroot/home@migrate
    $ zfs send -R zroot/home@migrate | ssh newhost zfs recv zroot/home

ZFS automatic snapshots (via zfstools[1]) can also saved hours of headaches trying to recover an older version of a file. Since snapshot appears as a regular mount (ZFS even automatically expose them under /path/to/mount/.zfs/snapshot), all existing tooling just works (cp, cat, running diff against snapshot, etc.).

My Linux machine these days also runs ZFS, but the level of integration with the system is still far from that of FreeBSD's. That can range from something as simple as ZFS ARC stats in top, to native support for ZFS Boot Environment allowing the system to boot directly from snapshots or do an offline upgrade of a clone of a live system[2]. (On Linux side of things there's zfsbootmenu[3] which provides something similar but the project is still quite new.)

The filesystem may not matter that much, and I'm sure many these features can be replicated with LVM, but having a unified tooling and community around it really makes quite a difference in quality of life as an end-user.

[1]: https://github.com/bdrewery/zfstools

[2]: https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-wi...

[3]: https://zfsbootmenu.org/

Not sure if it's still relevant (article is quite old after all), but does [1] still hold true in regards to /boot on ZFS on linux, even with zfsbootmenu? What kind of issues can I expect? Is there a newer/better knowledgebase compared to the one on pthree.org?

I'm guessing the newness/missing features of zfsbootmenu is in regards to beadm [2]?

[1] https://pthree.org/2013/01/03/zfs-administration-part-xvii-b... [2] https://vermaden.files.wordpress.com/2018/11/nluug-zfs-boot-...

GRUB2 works fine with /boot on ZFS, however GRUB cannot detect ZFS dataset with native ZFS encryption (see bug[1]). The best KB right now is probably OpenZFS documentation[2] and Arch Wiki[3].

I've been using ZBM since its inclusion in void-packages. It already does everything I wanted it to, but I don't think its usage is widespread outside Void Linux community just yet. Being dependent on Dracut might be one of the reason why (I believe Arch is still using mkinitcpio). There's installation instruction for Void and Debian Buster on ZBM GitHub[4]. I used to have a separate ZBM root for void-musl and void-glibc which worked quite well (though I'm now running only void-glibc due to Nvidia).

[1]: https://savannah.gnu.org/bugs/?func=detailitem&item_id=58270

[2]: https://openzfs.github.io/openzfs-docs/Getting%20Started/ind...

[3]: https://wiki.archlinux.org/title/Install_Arch_Linux_on_ZFS

[4]: https://github.com/zbm-dev/zfsbootmenu/wiki

Well I am running Ubuntu 20.04 and have experienced boot issues after update multiple times. Currently my laptop is not directly bootable as zpools are imported in wrong order / not imported at all so I have to import them manually. As there is not enough information how the freaking boot works and I am not prepared to study grub2 to figure it out and I am in this situation for 6 months.

This is my last root ZFS install on linux.

I had problems with fedora before (where at least ZFS wasnt supported and I was expecting problems), I am having problems with Ubuntu now and I never had any issues with zfs root on FreeBSD in ~15 years.

I am sick of distributions "moving fast and breaking things" on my back.

How do ZFS snapshots compare to LVM snapshots? Question not specifically for, but anyone who might know something about this.

Night and day. I hardly hear of anyone using LVM snapshots except in special cases, but ZFS snapshots for many people are like brushing one's teeth: a habit that is done multiple times a day.

Using them for system updates/upgrades is built right into FreeBSD (copying a feature from Solaris):

* https://www.freebsd.org/cgi/man.cgi?beadm

If the changes fail just rollback the system to the previous state/snapshot (including kernel changes) via the boot loader.

Services like rsync.net allow one to have offsite backups with easy, and the destination can be encrypted such that the remote end can't see your data. All through an SSH pipe.

Do you use Linux as a daily driver?

I used Linux as a daily driver until the end of 2020 (Void Linux + ZFS + ZBM), but now running M1 Mac as a primary machine. I'm still using Linux regularly though (gaming via Proton, which is why I'm not running FreeBSD on a desktop yet).

I can't speak for your computing experience, but for mine:

There are significant differences in performance, admittedly SSDs temper these differences but there are plenty of systems with large HDDs. This isn't an abstract performance benchmark thing, I feel it when doing operations on large numbers of small files.

There are significant differences in features that impact how you use the system. For instance, sometimes I like to backup a directory I'm working in (typically before some funky git operation), normally that can be done with cp or tar, but that's slow. Much faster is a manual filesystem(/volume manager) snapshot. But I have to remember to do that. Much more convenient would be if I didn't have to explicitly create a snapshot, which HAMMER would offer me.

All non-temporary HAMMER filesystems in DragonFly by default automatically maintain 60 days worth of 1-day snapshots and 1-day worth of fine-grained (30-second) snapshots. - https://www.dragonflybsd.org/features/#index3h2

It sure does. Compression and encryption and snapshotting and bit rot protection all native to the file system and the tools around it instead of having to cobble together lvm and mdraid and such.

Snapshotting imo is one of the best things. Copy on write file systems really are awesome. And FreeBSD adopting ZFS so early was a huge win imo.

Depends. In a perfect world it doesn't matter. However in this imperfect world it is nice to know that there is an automatic backup of your files from a few days ago, and if a hard drive crashes you just replace it (requires paying for redundant hard drives!). The ability to add more space to an existing filesystem is nice just in case.

There are a lot of other features that might or might not matter to you. If the above don't it is because you haven't been burned yet in life. (Or you use one of several other filesystems that support those features)

Short answer - automatically cache frequently-accessed files on expensive but small NVMe drives while using bigger cheaper slower drives for mass storage.

Yes, I agree, and sorry for the ignorant question. Yet a lone "educate yourself" may be a bit harsh on a site where informal technical conversation happens. Care to share a couple of "killer" features of ZFS for somebody who has never cared about the FS their files are stored in?

Too much to write and too many features, that's what i meant with educate yourself:

https://en.wikipedia.org/wiki/ZFS