On 10/06/2014 10:26 AM, Josef Bacik wrote:
On Mon, Oct 6, 2014 at 9:50 AM, Ric Wheeler <rwheeler@xxxxxxxxxx> 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 :)
ric
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
