btrfs as default filesystem for F22?

[Eric Sandeen]

On 10/6/14 8:50 AM, Ric Wheeler wrote:
> On 10/06/2014 08:54 AM, Josef Bacik wrote:
>> 
>> Well that's exactly what it is, go away I'm busy with other stuff
>> :).  The fact is I'm the only one who can drive btrfs as the
>> default filesystem feature in Fedora, and since I've left Red Hat
>> that has become much less of an priority for me.  But my "other
>> stuff" is still mostly related to btrfs, so its not like this has
>> just been abandoned, the focus has just shifted and I no longer
>> feel like we need to be using btrfs as the default fs in Fedora to
>> have a successful project, so it got moved down the priority list.
>> It will happen, and when it happens it will be relatively painless
>> because Suse will have worked out a lot of the distro esque kinks
>> and us at Facebook will have worked out a lot of the at scale
>> kinks.  Thanks,
>> 
>> Josef
>> 
> 
> I think that the out of space issues are not that different from any
> file system on write enabled snapshots - it certainly can be
> mysterious and confuse users, but that is something that we have to
> deal with in order to get this kind of sophistication into end users
> hands (documentation? better tooling like the snapper tool, etc?).
> 
> One of the harder challenges I think for btrfs is still getting the
> repair tools rock solid - how is our track record these days with
> repairing btrfs after bad things happen :) ?

In my recent (past couple weeks) testing, it's dismal, although a bunch
of fsck patches have shown up on the list which I haven't tried yet.

Doing what I considered to be light fuzzing of a filesystem, and attempting
a btrfsck & mount led to segfaults, aborts, and mount failures the vast
majority of the time - more or less often, depending on the particular metadata
layout.  Other filesystems fared much better in this testing.

And the best-practice repair strategy with btrfs is still not clear to me;
there is btrfs check (aka btrfsck) of course, with various suboptions the
admin should know about: init-csum-tree, init-extent-tree, backup, subvol-extents;
several of these are not documented ... and also mount options:
-o degraded, -o recovery, -o skip_balance.  And other tools; btrfs
rescue, with various suboptions - super-recovery, chunk-recover.
There's btrfs scrub, which will work online and "Errors are corrected along the
way if possible." and btrfs-rescue, a last-ditch effort to extract files
from the smoking remains of an otherwise unrescuable filesystem.

It may be that I'm just not up to speed on btrfs - I've realized that I can't
be an in-depth expert on 3 different filesystems - but to me, the filesystem
repair and recovery plan for btrfs is not at all reliable or obvious or clear.

(I need to send this same post to the btrfs-list, I guess, but I did want to
point out that it is, to me, a big concern for Fedora decision-making.  btrfs
was first proposed as default in F17, 3 years ago, and ISTR reliable fsck being a
gating item back then.  And now here we are...)

Thanks,
-Eric