On Mon, Mar 12, 2018 at 11:17:21PM +0000, Carsten Mattner wrote: > On 3/12/18, Leonid Isaev via arch-general <arch-general@archlinux.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 [1]. 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. Hmm, btrfs-send(1)? [1] https://news.ycombinator.com/item?id=14907771 Cheers, -- Leonid Isaev
