On Wed, Apr 15, 2020 at 2:31 PM james <[email protected]> wrote:
>
> On 4/15/20 11:40 AM, Rich Freeman wrote:
>
> > I personally use the latest longterm, but not until it has been out
> > for a few months.  Mainly this is because I use zfs and don't want to
> > deal with what versions of the one are compatible with what versions
> > of the other.
>
> Yep, for the main system, but using btrfs with redundant drives. I'd
> like zfs, but not certain about it's future being open, open-source,
> etc. btrfs has bee great, for what I have done recently.
>

So, a few comments here:

First, I used to use btrfs and I'd say it is just as important to
stick with a longterm using btrfs because that project has a terrible
history of introducing regressions in new kernel releases.  If I were
using btrfs I'm not sure I'd even go with 5.4 over 4.19 as it has only
been around a few months and I'd be concerned they haven't worked out
all the btrfs bugs yet.

Now, I haven't used btrfs recently, so maybe things have gotten much
better, but I'm skeptical on that front.  I've had to do complete
btrfs reinstalls more than once from backups, and this was on btrfs
raid1 only.  I REALLY like the feature set and design/etc of btrfs and
think it definitely could be the future of linux mainstream storage,
but for whatever reason QA has been a big problem and it has taken way
longer than I expected to mature.  It was btrfs QA problems that drove
me to pay such close attention to what kernel series I was running.

That is why I've mainly moved to zfs as my main general-purpose
filesystem on hosts where restoring from backup isn't about popping an
SDcard out of a Pi and flashing a couple GB backup image onto it.

I'm not entirely happy with some of the limitations of zfs and of
course it not being in-mainline is a huge hassle.  There really is no
risk of it not being FOSS - it is FOSS and of course it always will be
as is the case with anything FOSS.  Whether anybody is contributing to
it in 10 years is another matter, but it isn't like the license has an
expiry date on it.  The #3 openzfs contributor is a Gentoo dev.  I
suspect the main risk to zfs is that btrfs finally gets its quality
level up sufficiently that people switch over, which would be great.
Either that or zfs gets sloppy with QA and people abandon it, which
would be terrible, but probably unlikely at this point.

For larger-scale storage I'm using Lizardfs and greatly admire Ceph as
well in this space.  MooseFS is another option (which Lizardfs is a
fork of).  These distributed filesystems are generally more flexible
than zfs and give you redundancy above the host level.  Right now the
bulk of my storage is on lizardfs with the lizardfs chunkservers being
implemented on top of zfs.  That gives me the data security benefits
of zfs but without the inflexibility, since I don't pool drives so I'm
not limited by the ability to add/remove/etc drives from zfs pools.
That said, vdev removal has become a thing in v0.8 and perhaps we'll
see increased flexibility in the future.

Overall zfs and btrfs are actually converging somewhat, just from
different target audiences.  IMO with the growing importance of
distributed filesystems I think that the main niche for zfs and btrfs
will be as a general-purpose filesystem similar to ext4 but with
additional flexibility (volume management) and robustness
(raid/checksums/etc).  Once you get bigger than a few drives Ceph will
become the gold standard for storage, or at least that is the leading
technology right now.  Lizardfs is more of a ghetto Ceph that doesn't
require dozens of GB of RAM per server.

If you haven't been upgrading kernels you may have just missed all the
fun of btrfs regressions over recent years.  :)  In any case unless
things have changed a lot I'd seriously consider longterms and then
carefully checking for regressions before doing upgrades between major
versions.

-- 
Rich

Reply via email to