On Sun, May 11, 2014 at 10:10:41AM +0100, Hugo Mills wrote: > a) The chunk tree is whole and consistent > b) We need to (or have been asked to) rebuild the chunk tree from scratch > > So I think, yes, you can make fake metadata blocks, but you have to > rely on either (a) your fake data being written to exactly the right > place and not overwritten by a balance, or (b) having the chunk tree > broken and the admin looking for a usable set of metadata with > btrfs-find-root and choosing your fake (with enough plausible complex > data in it to fool them). > > I've probably missed loads of points here, but I think this is a > good start for the conversation. :) I think you've covered most of it. One thing that looks as a show stopper is the fact that the fake data blocks that would become the metadata blocks would lie out of any metadata group. I'm not familiar with the chunk rebuilder, but this seems as a simple check to do when it tries to guess the block group layout from what it finds on disk. Otherwise, faking the metadata block contents seems very fragile, we'd need at least some knowledge where the block will end up in the key space and also something about the adjacent blocks -- all must fit at the time when the fsck will happen. The logical offset of the block is incorporated in the metadata blocks in the upper layers as a key and this propagates up the tree, so replacing one block pointer would disrupt the key ordering, unless it's at the beginning/end of a gap in the key space so it could point to a data blockgroup. Replacing a chain of nodes would need a correct parent transaction ids that match the current state of the fs. *more handwaving* -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
