Yeah "apk add ZFS" is very scary and off the beaten path :)

That's all you need to use ZFS data drives on alpine. On root is admittedly a lot more complex though.

Is it particularly helpful to use ZFS on root?

ZFS on root (and setting up automatic snapshots) is great for rollbacks if a system update turned out bad, and also allows for being certain there’s no corruption after a power failure or a disk starts getting flaky. It also makes sending off snapshots for a backups a breeze.

So it’s not really for day to day issues, it’s more for turning a rare “day of pain” into something much less.

AFAIK, for events like unexpected power failure, ZFS is always consistent to the point of the last complete TxG. No snapshot required (and it wouldn't provide more-recent data, either) to deal with power failure-induced data corruption, because there isn't any.

And also AFAIK, ZFS snapshots don't protect against data corruption from flaky disks: An online snapshot doesn't make a copy of anything. (That's more like what RAIDZ or copies=2 are for.)

Snapshots do make great rollback methods, even for fixing dumb day-to-day mistakes. (I mean, I'm sure none of us have ever done something stupid with a computer, but it probably happens to someone sometimes.) And they are indeed easy to send elsewhere to be used as complete backups of a dataset's state at a single point in time.

And there's other good stuff about daily use of ZFS root, too: Datasets. Like other filesystems, ZFS does occupy an entire disk (or a partition on that disk) -- in this case a "pool".

But within that pool can be many, many datasets that are independent of one-another, just sharing space in the pool. One linux distro's root might occupy one dataset, and another more-experimental (or major breaking upgrade) distro's root might occupy another dataset. /home can be on a third dataset that both distros use. This is a very wonderful thing for those with limited hardware budgets -- gone are the days of resizing/paring down disk partitions just to try something different. (Datasets can also be copied or moved to different pools and those pools can be different sizes.)

Or: Caching. Now that persistent l2arc is a thing, a snappy-feeling system can be built with big (redundant!) spinning disks, and a relatively small (fast!) SSD as a read cache.

It's not really just for "day of pain" issues -- ZFS is pretty slick in all kinds of useful ways, as a root filesystem and elsewhere.

I've actually used snapshots to roll back an upgrade that got messed up. Of course, Alpine is stable enough that it doesn't exactly come up a lot:)

It's incredibly useful yes.

For starters you have the snapshots which you can use as 'restore points' like in Windows to go back when an update breaks something. Except this time they actually do work (I've never had that fix anything for me on windows).

You can also use them to try out huge packages like different DEs on your daily driver and revert if you don't like it without having to remove the entire forest of dependencies.

You can also silence the filesystem for backups similar to volume shadow copy in Windows. ZFS send/receive is also a fast way to actually make backups although it has some serious drawbacks so I don't use it (mainly the inability to restore individual files)

Another thing is that you can base filesystems upon other ones so you can use it to create one jail (like docker container) that you keep updated and base your other ones off it. A bit like docker layers do. Yes this one is very FreeBSD specific.

And finally, doing a scrub to check for bitrot can really save your bacon.

So in my examples most useful features stem from its snapshot functionality.

From what I do observe, people with desktop usage cases tend to favor it - to be able to rollback updates/upgrades.

Not sure why not btrfs for desktop usage, may be it's just not discussed much comparing to ZFS fans.

On servers I personally avoid ZFS do be involved into boot sequence - just for data storage stuff