Re: [gentoo-user] Re: beegfs goes opensource!

[Rich Freeman]

On Sun, Feb 28, 2016 at 8:34 AM, Tanstaafl <tanstaafl@×××××××××××.org> wrote:
>
> Also, it has been a while since I read anything - what is the current
> state of BTRFS vs ZFS? Is it stable/mature enough to use for production?
> What can ZFS do that it cannot?
>

This is obviously a topic people will have various opinions on.

I'd say that zfs is more stable, but long-term less likely to be the
mainstream linux solution.

At the current time I'd say that btrfs single-disk or in raid1 is
mature enough to be usable, with a bunch of caveats.  It definitely
isn't up there with the likes of ext4.  Besides some stuff just not
being handled gracefully like low-disk-space it is fairly prone to
regressions.  I've found I've gotten the best experience by sticking
with longterm kernels and not updating to the next one until it
reaches maybe x.x.16 or so (maybe 6mo after release), and I always
check the lists before updating.

As far as features go, zfs tends to have more enterprise-oriented
features and btrfs tends to have more small-system-oriented features.
For example, in zfs with 100 drives you can arrange them into 10 neat
raid-6s with 10 drives each or something along those lines, and have a
few SDDs servicing the entire array as read and write caches.  On the
other hand, if you have a 4-drive raid5 and want to turn it into a
5-drive raid5 this is impossible to do in zfs without copying all the
data off the drives, but trivial to do in btrfs.  When you have 100
drives adding or removing 10 at a time probably isn't a big deal, but
when you 4 drives having to first add 5 drives and then remove the
previous 4 seems almost comical.  It just has to do with the original
goals of the two filesystems.

Oh, I've heard that zfs is ram-hungry, and many of its advocates
suggest it should only be used with ECC RAM.  Honestly, I've never
seen an argument for ECC on zfs that wouldn't apply equally to any
other filesystem, but whatever.  I haven't found btrfs to be terribly
RAM hungry, but I have found that it doesn't seem to do a good job
with IO scheduling classes (though I have no idea how zfs does on this
front).  Btrfs at least seems to accept too many writes into its queue
and then everything backlogs with getting it all out to disk,
resulting in processes that should be low-priority blocking writes
even on processes marked as realtime.  I suspect that this is just the
whole bufferbloat phenomena in another context.

I'm not really sure what the "conservative" recommendation.  Ext4 (or
even ext3) is the obvious one, but both zfs and btrfs have
checksumming of all data written to disk which is a huge data security
improvement.  That is a compelling feature that should give even
conservative sysadmins pause before just rejecting them, unless
they're mitigating silent corruptions in some other way.

-- 
Rich