On 2016-09-19 16:15, Zygo Blaxell wrote:
On Mon, Sep 19, 2016 at 01:38:36PM -0400, Austin S. Hemmelgarn wrote:
I'm not sure if the brfsck is really all that helpful to user as much
as it is for developers to better learn about the failure vectors of
the file system.
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?
I'd really prefer to be able to delete the dead dentry with 'rm' as root,
or failing that, with a ZDB-like tool or ioctl, if it's the only known
instance of such a bad metadata object and I already know where it's
located.
I entirely agree on that. The problem is that because the VFS layer
chokes on it, it can't be rm, and it would be non-trivial to implement
as an ioctl. It pretty much has to be out-of-band. I'd love to see
btrfs check add the ability to process subsets of the filesystem (for
example 'I know that something is screwed up somehow in
/path/to/random/directory, check only that path in the filesystem
(possibly recursively) and tell me what's wrong (and possibly try to fix
it)').
Usually the ultimate failure mode of a btrfs filesystem is a read-only
filesystem from which you can read most or all of your data, but you
can't ever make it writable again because of fsck limitations.
The one thing I do miss about every filesystem that isn't ext2/ext3 is
automated fsck that prioritizes availability, making the filesystem
safely writable even if it can't recover lost data. On the other
hand, fixing an ext[23] filesystem is utterly trivial compared to any
btree-based filesystem.
For a data center or corporate entity, dropping broken parts of the FS
and recovering from backups makes sense. For a traditional home user
(that is, the type of person Ubuntu and Windows traditionally target),
it usually doesn't, as they almost certainly don't have a backup.
Personally, I'd rather have a tool that gives me the option of whether
to try and fix a given path or just remove it, instead of assuming that
it knows how I want to fix it. That would allow for both use cases.
--
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
