On 2016-09-19 14:27, Chris Murphy wrote:
On Mon, Sep 19, 2016 at 11:38 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
ReiserFS had no working fsck for all of the 8 years I used it (and still
didn't last year when I tried to use it on an old disk). "Not working"
here means "much less data is readable from the filesystem after running
fsck than before." It's not that much of an inconvenience if you have
backups.
For a small array, this may be the case. Once you start looking into double
digit TB scale arrays though, restoring backups becomes a very expensive
operation. If you had a multi-PB array with a single dentry which had no
inode, would you rather be spending multiple days restoring files and
possibly losing recent changes, or spend a few hours to check the filesystem
and fix it with minimal data loss?
Yep restoring backups, even fully re-replicating data in a cluster, is
untenable it's so expensive. But even offline fsck is sufficiently
non-scalable that at a certain volume size it's not tenable. 100TB
takes a long time to fsck offline, and is it even possible to fsck 1PB
Btrfs? Seems to me it's another case were if it were possible to
isolate what tree limbs are sick, just cut them off and report the
data loss rather than consider the whole fs unusable. That's what we
do with living things.
This is part of why I said the ZFS approach is valid. At the moment
though, we can't even do that, and to do it properly, we'd need a tool
to bypass the VFS layer to prune the tree, which is non-trivial in and
of itself. It would be nice to have a mode in check where you could say
'I know this path in the FS has some kind of issue, figure out what's
wrong and fix it if possible, otherwise optionally prune that branch
from the appropriate tree'. On the same note, it would be nice to be
able to manually restrict it to specific checks (eg, 'check only for
orphaned inodes', or 'only validate the FSC/FST'). If we were to add
such functionality, dealing with some minor corruption in a 100TB+ array
wouldn't be quite as much of an issue.
--
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
