btrfs as default filesystem for F22?
rwheeler at redhat.com
Mon Oct 6 18:19:06 UTC 2014
On 10/06/2014 10:26 AM, Josef Bacik wrote:
> On Mon, Oct 6, 2014 at 9:50 AM, Ric Wheeler <rwheeler at redhat.com> 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,
>> 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 :) ?
> Funny you should ask, I just added a bunch of functionality last week!
> So right now our fsck fixes anything wrong in the extent tree, which
> is where a majority of the problems happen. The other side of course
> is the fs tree which is infinitely easier to deal with, but I usually
> wait for a user with a broken fs to fix before adding the ability to
> fix it into fsck so I'm sure we have a good testcase to work against.
> Every fix I add to fsck gets a test image added to btrfs-progs to make
> sure we're never regressing.
> Obviously we aren't in xfs/e2fsprogs territory, but it'll fix 90% of
> the problems and then the other 10% are just a matter of having an
> example to work off of. Thanks,
One of the things that the GFS2 people have done really well in helping their
repair tools is to keep an anonymized (file names randomized, data blocks
skipped) set of corrupt file system metadata layouts around to use to verify the
tools. Every time they hit a really nasty file system, they try to get this
kind of dump so they can validate the tools...
Adding in Bob who does most of this :)
More information about the devel