btrfs as default filesystem for F22?

[Josef Bacik]

On Mon, Oct 6, 2014 at 2:19 PM, Ric Wheeler <rwheeler at redhat.com> wrote:
> 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,
>>>>
>>>> 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 :) ?
>>>
>> 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,
>>
>> Josef
>
>
> 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 :)
>

Yup we have something similar, btrfs-image will pull all the metadata
off of the fs and compress it and then I can replay it to have
something to reproduce on.  We have a sanitize option that will
sanitize filenames and such if the user cares about that.  I'm pretty
happy with fsck at this point and it is really easy for me to fix it
to fix whatever new corruption we've found, its everything else that's
making me go prematurely bald (well ok maybe Liam is to blame for most
of that too.)  Thanks,

Josef