On Mon, Mar 12, 2018 at 11:17:21PM +0000, Carsten Mattner wrote:
> On 3/12/18, Leonid Isaev via arch-general <firstname.lastname@example.org> wrote:
> > What's wrong with btrfs? Yeah, I know it is not marked "stable", but this
> > is just a label. And people shying away from it doesn't help in advancing
> > its stability either.
> btrfs never got on my radar because it's Linux only and its instability
> is a blocker. If I have to be careful how I use a filesystem even when
> I didn't explicitly enable beta features, I'm too scared to put my files
> on it. If I were a Suse Enterprise customer, I might use it, but Red Hat
> isn't behind it anymore, so it's like Reiser3 back in the day. Only Suse
> was putting their weight behind it. Well Facebook has developers on it,
> but Facebook isn't a distro developer and can't be trusted with continued
> maintenance, since they might switch on a weekend to some Facebook-FS.
> Facebook has too many engineers and is reinventing stuff in-house a lot.
This is all corporate politics, but see first comment here . And you still
haven't explained what instability? I use btrfs on all my machines, including
its subvolume/snapshot features to protect against failed updates (essentially,
I reimplemented some features of snapper in bash :) because I don't like dbus).
Of course, you need to do scrubbing regularly, but it's trivial to write a cron
job/systemd timer for this task...
> btrfs and zfs suffer from design limitations, but zfs has been stable
> and in petabyte production for a long time across many organizations.
> btrfs is one of many future Linux filesystems with no clear winner
> so far.
If noone uses it, then sure, btrfs will remain an underdog of filesystems.
Also, if you care about petabyte production, you should know better than asking
on this list...
> All I want is a modern filesystem whose volume I can share without
> exposing it via a network protocol.