All of lore.kernel.org
 help / color / mirror / Atom feed
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.