On Sun, Mar 11, 2018 at 07:56:37PM +1100, Russell Coker wrote:
> On Sunday, 11 March 2018 6:37:56 PM AEDT Craig Sanders via luv-main wrote:
> > On Fri, Mar 09, 2018 at 07:49:48PM +1100, Russell Coker wrote:
> > > Unlike BTRFS, you can expect every feature of ZFS to just work.  It may be
> > > a total PITA to get it working, it may not be something you even want to
> >
> > ZFS just works, and I've never found it to be a PITA at all.  I've been
> > using it since around 2010.
>
> BTRFS snapshots just appear ready to use.  ZFS snapshots have to have extra
> stuff done to expose them.  Snapshots of ZFS block devices have similar levels
> of pain.

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/


> >  * non-rootfs storage just works - no hassle, no fuss, no drama. Couldn't
> > be easier...certainly a lot less work/hassle than LVM and/or mdam + ext4
> > or xfs.
>
> If the installer supported it then that would be the case.  As an aside does
> the Ubuntu installer support ZFS?

no idea. the last time I used an ubuntu installer was long before they started
supporting ZFS.

> But given that you can just install straight to mdadm+LVM+Ext4 or BTRFS, in
> Debian at least ZFS is much harder to use.

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.


> >  * getting linux to boot from ZFS requires some work (unless your distro
> > supports it natively, like Ubuntu).  A few hours of reading and about the
> > same of careful, methodical work the first time you do it.
>
> Or you decide that something that requires a few hours of reading might be
> too fragile for your root filesystem.

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


> >    IMO it's worth the effort just for snapshots & zfs send backups of the
> >    rootfs.  All the other ZFS features are just gravy.
>
> You can have a cron job that rsyncs the root on Ext4 to ZFS and then uses
> ZFS snapshots etc for managing backups.

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 <c...@taz.net.au>
_______________________________________________
luv-main mailing list
luv-main@luv.asn.au
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Reply via email to