On Tue, Sep 13, 2016 at 5:35 AM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote: > On 2016-09-12 16:08, Chris Murphy wrote: >> >> - btrfsck status >> e.g. btrfs-progs 4.7.2 still warns against using --repair, and lists >> it under dangerous options also; while that's true, Btrfs can't be >> considered stable or recommended by default >> e.g. There's still way too many separate repair tools for Btrfs. >> Depending on how you count there's at least 4, and more realistically >> 8 ways, scattered across multiple commands. This excludes btrfs >> check's -E, -r, and -s flags. And it ignores sequence in the success >> rate. The permutations are just excessive. It's definitely not easy to >> know how to fix a Btrfs volume should things go wrong. > > I assume you're counting balance and scrub in that, plus check gives 3, what > are you considering the 4th?
- Self repair at mount time, similar to other fs's with a journal - fsck, similar to other fs's except the output is really unclear about what the prognosis is compared to ext4 or xfs - mount option usebackuproot/recovery - btrfs rescue zero-log - btrfs rescue super-recover - btrfs rescue chunk-recover - scrub - balance check --repair really needed to be fail safe a long time ago, it's what everyone's come to expect from fsck's, that they don't make things worse; and in particular on Btrfs it seems like its repairs should be reversible but the reality is the man page says do not use (except under advisement) and that it's dangerous (twice). And a user got a broken system in the bug that affects 4.7, 4.7.1, that 4.7.2 apparently can't fix. So... life is hard, file systems are hard. But it's also hard to see how distros can possibly feel comfortable with Btrfs by default when the fsck tool is dangerous, even if in theory it shouldn't often be necessary. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
