From: Kalpak Shah <Kalpak.Shah@Sun.COM>
To: TheodoreTso <tytso@mit.edu>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: [e2fsprogs] Failing extents tests
Date: Mon, 29 Sep 2008 19:17:35 +0530 [thread overview]
Message-ID: <1222696055.3971.42.camel@localhost> (raw)
Hi,
The extents support in e2fsprogs-1.41.1 doesn't pass a few of the
regression tests that we had created. 4 tests out of 20 are failing, I
have included some details about the failures.
e2fsprogs-tests-f_extents_ee_len.patch: Corrupt ee_len is not detected.
e2fsprogs-tests-f_extents_ei_block.patch: Corrupt ei_block is not
detected. In the Sun extents code, we passed the previous extent to
ext2fs_extent_verify(), so additional sanity checks could be performed.
Here is a snippet of that:
/* Verify that a single extent @ex is valid. If @ex_prev is passed in,
* then this was the previous logical extent in this block and we can
* do additional sanity checking (though in case of error we don't know
* which of the two extents is bad). Similarly, if @ix is passed in
* we can check that this extent is logically part of the index that
* refers to it (though again we can't know which of the two is bad). */
errcode_t ext2fs_extent_verify(ext2_filsys fs, struct ext3_extent *ex,
struct ext3_extent *ex_prev,
struct ext3_extent_idx *ix, int ix_len)
Similarly we also passed previous ext3_extent_idx to
ext2fs_extent_index_verify().
Maybe we can do something similar by adding ex_prev and ix_prev to
ext2_extent_handle_t?
e2fsprogs-tests-f_extents_imbalanced_tree.patch,
e2fsprogs-tests-f_extents_eh_depth.patch: In both these cases, e2fsck
aborts with a "Corrupt extent header on inode %i" error. Instead of
aborting we can clear the extent header and set i_blocks to 0?
I have uploaded these tests at
http://downloads.lustre.org/public/tools/e2fsprogs/extent_tests/
One problem with these tests is that, the high 16 bits of extent/index
block are set, so these tests cannot be used as-is, but the image should
be helpful to check if the problem is solved or not.
Thanks,
Kalpak
reply other threads:[~2008-09-29 13:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1222696055.3971.42.camel@localhost \
--to=kalpak.shah@sun.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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