On Wed, Dec 16, 2015 at 01:03:38PM +0100, Christoph Anton Mitterer wrote: > On Tue, 2015-12-15 at 14:18 +0000, Hugo Mills wrote: > > That one's easy to answer. It deals with a major issue that > > reiserfs had: if you have a filesystem with another filesystem image > > stored on it, reiserfsck could end up deciding that both the metadata > > blocks of the main filesystem *and* the metadata blocks of the image > > were part of the same FS (because they're on the same block device), > > and so would splice both filesystems into one, generally complaining > > loudly along the way that there was a lot of corruption present that > > it was trying to fix. > Hmm that's a bit strange though, and to me it rather sounds like other > bugs... > You can have a ext4 on a file in an ext4, with or without the same > UUIDs, and it will just work.
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. Since there was no uuid, it was impossible to tell if a block from the scan was really part of this filesystem or part of some image file that happened to be sitting there. 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. At the end of the day it's just a best practice mechanism to help recovery and prevent admin mistakes. It's also a building block of the multi-device support. We could change the multi-device support to allow duplicate uuids in single device filesystems. But I'd much rather see a variation on seed devices enable transitioning from one uuid to another. > If the filesystem takes contents from a normal file as possible > metadata, than something else is severely screwed up... or in case of > the fsck: it probably means it's a bit too liberal in searching places. > > I'd be quite shocked if this is the case in btrfs, cause it would mean > again, that we have a vulnerability against UUID collisions. > Imagine some attacker finds out the UUID of a filesystem (which is > probably rather easy)... next he uploads some file (e.g. it's a > webserver with allows image uploads, a forum perhaps) that in reality > contains what's looks like btrfs metadata and uses a matching UUID. > > It would run into the same issues as what you describe for reiser,.. > the UUID would be no real help to solve that problem. > > > 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. -chris -- 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
