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.
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.