From: Theodore Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>, forrestl@synology.com
Subject: Re: [PATCH 1/3] e2fsck: fix incorrect interior node logical start values
Date: Mon, 24 Dec 2012 09:57:02 -0500 [thread overview]
Message-ID: <20121224145702.GA10888@thunk.org> (raw)
In-Reply-To: <50D4CAFE.5010606@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
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 #2: leaf-node-overlap.img.gz --]
[-- Type: application/octet-stream, Size: 682 bytes --]
prev parent reply other threads:[~2012-12-24 14:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-13 15:32 [PATCH] ext4: fix extent tree corruption that incurred by hole punch [V2] Forrest Liu
2012-12-13 16:04 ` Forrest Liu
2012-12-13 16:17 ` Forrest Liu
2012-12-14 17:18 ` Eric Sandeen
2012-12-17 4:25 ` Ashish Sangwan
2012-12-20 5:39 ` Theodore Ts'o
2012-12-20 15:11 ` Forrest Liu
2012-12-20 23:42 ` Theodore Ts'o
2012-12-20 23:43 ` [PATCH 1/3] e2fsck: fix incorrect interior node logical start values Theodore Ts'o
2012-12-20 23:43 ` [PATCH 2/3] libext2fs: ext2fs_extents_fix_parents() should not modify the handle location Theodore Ts'o
2012-12-20 23:43 ` [PATCH 3/3] e2fsck: make sure the extent tree is consistent after bogus node in the tree Theodore Ts'o
2012-12-21 3:19 ` Theodore Ts'o
2012-12-21 11:02 ` Forrest Liu
2012-12-21 15:34 ` Eric Sandeen
2012-12-21 20:47 ` [PATCH 1/3] e2fsck: fix incorrect interior node logical start values Eric Sandeen
2012-12-24 14:57 ` Theodore Ts'o [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121224145702.GA10888@thunk.org \
--to=tytso@mit.edu \
--cc=forrestl@synology.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).