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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
