On Wed, 2015-12-16 at 09:41 -0500, Chris Mason wrote: > Hugo is right here. reiserfs had tools that would scan and entire > block > device for metadata blocks and try to reconstruct the filesystem > based > on what it found. Creepy... at least when talking about a "normal" fsck... good that btrfs is going to be the next-gen-ext, and not reiser4 ;)
> Adding UUIDs doesn't make that whole class of problem go away (you > could > have an image of the filesystem inside that filesystem), but it does > make it dramatically less likely. Sure... > > Does anyone know whether btrfsck (or other userland) tools do such > > things? I.e. search more or less arbitrary blocks, where it cannot > > be > > sure it's *not* data, for what it would interpret as meta-data > > subsequently? > > These are emergency tools, btrfs restore and find-roots can do some > scanning. We don't do it the way reiserfs did because it would be > very > difficult to reconstruct shared data and metadata from snapshots. Hmm I agree, that it's valid for such tools, to do these kinds of scans (i.e. scan for meta-data in places that are not known for sure to be meta-data) when doing some last-resort-rescue tries... or for rescue operations, where it's clearly documented that this is done. But I think it shouldn't happen e.g. during a normal fsck - only when special options are given. And it should be properly documented (i.e. telling people in the docs, that this does a block for block scan for meta-data even within normal data, and that if they'd had e.g. another fs of the same UUIDs within, the results may be completely bogus. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
