[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20121224145702.GA10888@thunk.org>
Date: Mon, 24 Dec 2012 09:57:02 -0500
From: Theodore Ts'o <tytso@....edu>
To: Eric Sandeen <sandeen@...hat.com>
Cc: Ext4 Developers List <linux-ext4@...r.kernel.org>,
forrestl@...ology.com
Subject: Re: [PATCH 1/3] e2fsck: fix incorrect interior node logical start
values
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
Download attachment "leaf-node-overlap.img.gz" of type "application/octet-stream" (682 bytes)
Powered by blists - more mailing lists