On Fri, Dec 21, 2012 at 02:47:58PM -0600, Eric Sandeen wrote: > > Hm, this situation might still need more work in some cases. > > but in this case, it seems that the length of the range covered by > the previous interior nodes is still incorrect. :( Yep, we've got a problem which e2fsck is not detecting. Here's a simple test case which shows the problem: debugfs: extents <12> Level Entries Logical Physical Length Flags 0/ 2 1/ 2 0 - 6 23 7 1/ 2 1/ 2 0 - 3 18 4 2/ 2 1/ 2 0 - 0 37 - 37 1 Uninit 2/ 2 2/ 2 2 - 21 50 - 69 20 Uninit <----- this conflicts 1/ 2 2/ 2 4 - 6 21 3 <----- with this 2/ 2 1/ 2 4 - 4 39 - 39 1 Uninit 2/ 2 2/ 2 6 - 6 40 - 40 1 Uninit 0/ 2 2/ 2 7 - 10 24 4 1/ 2 1/ 2 7 - 8 20 2 2/ 2 1/ 2 7 - 7 41 - 41 1 Uninit 2/ 2 2/ 2 8 - 8 42 - 42 1 Uninit 1/ 2 2/ 2 9 - 10 22 2 2/ 2 1/ 2 9 - 9 43 - 43 1 Uninit 2/ 2 2/ 2 10 - 10 44 - 44 1 Uninit In this case it's not obvious what is the right fix, since we have two physical blocks which claim to map to the same logical block. There are some places already in e2fsck where we today just throw up our hands and offer to zap the entire inode, instead of trying to let the user decide which is the correct physical blocks to use, or do some way of saving out the conflicting inodes. It may be that's the best way to fix this, since at the very least should be detecting that there is a problem, and fixing it somehow. We can always try to come up with a better way of repairing the corruption later. Attached is a test case file system image with the above extent tree. - Ted
Attachment:
leaf-node-overlap.img.gz
Description: Binary data
