On Sun, Mar 11, 2018 at 07:56:37PM +1100, Russell Coker wrote: What, you mean `zfs set snapdir=visible pool/dataset` or `zfs set snapdev=visible pool/zvol` is difficult? (like most other attributes, these are inherited by default by child datasets, and can be enabled/disabled individually) The only thing difficult about visible snapshots in ZFS is realising that tools like rsync will recurse into the .zfs/ snapshot directory unless you tell them not to. e.g. for rsync you can use a .rsync-filter file like this: $ cat /.rsync-filter -r .zfs/*** -s .zfs/*** - /tmp/*** See http://blog.taz.net.au/2012/04/01/rsync-and-zfs-snapshot-directories/ no idea. the last time I used an ubuntu installer was long before they started supporting ZFS. We obviously have different definitions of 'difficult to use'. I'd agree with "a bit more difficult to set up". but definitely not with "much harder to use". There are enough howtos and blog posts and answers on sites like stackexchange detailing how to get your rootfs on ZFS that it doesn't even qualify as "much harder to setup", only "a bit harder". When it comes to actually using either ZFS or LVM to administer your systems and organise your filesystems/datasets & partitions/zvols, ZFS wins for ease of use - it's not even a contest. LVM was good in it's day, but that day was over long ago. "requires research and work to set up" does not equal "fragile". Personally, I think anyone who doesn't take the time to research how to best use the tools at their disposal, and which of the many tools to use, is negligent. ZFS doesn't require research because it's extremely difficult to use or understand. It requires research because it can do a lot, and there are many different ways to configure and use it. To make good choices you need some understanding of the concepts and you need some familiarity with the tools. Any complex/flexible tool will require a similar level of research effort. Yes, i still do that on my systems that don't have zfs for the root fs. rsync's a great tool, but it doesn't come close to `zfs snapshot ...` followed by `zfs send`. `zfs send` completes in a tiny fraction of the time that an rsync takes, with much lower disk I/O. Incremental daily backups that used to take tens of minutes or even hours to complete - even with hardly any changes - now complete in a just few minutes. I barely even notice when the backup jobs start at ~1am - they used to be a sign that I should go to bed because my system will be running at a crawl, thrashing the disks for the next few hours. This is entirely due to rsync having to examine at least the metadata for each file in the directory tree being backed up (and possibly compare the block checksums on both sides of the rsync). With `zfs send`, ZFS knows **exactly** which blocks have changed in that snapshot, no lookup or scan required - just send the changed blocks. Even the startup time of rsync, while it's doing its initial scan of the backup path is several times longer than an entire zfs send backup. As I said, this alone makes it worth using ZFS for the rootfs. Like LVM, rsync was a great tool for its day. Unlike LVM, it's still worth using for some things. IMO the only reason to use LVM these days is because you have legacy systems that can't be taken down long enough to convert to ZFS (but you should be planning to switch them to ZFS in some future hardware upgrade/replacement). I'd really like that to be true for btrfs too, but it's just not reliable enough to be considered in the same league as ZFS. btrfs' feature set isn't as complete as ZFS (although it does have rebalancing, which is the one great thing it has that ZFS doesn't), but they're good enough that it would be a worthy option if you could trust it not to lose your data in some disaster. craig -- craig sanders <cas(a)taz.net.au>