From: Ted Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Updated test case
Date: Sun, 22 Aug 2010 07:42:28 -0400 [thread overview]
Message-ID: <20100822114228.GB6329@thunk.org> (raw)
In-Reply-To: <4C7071EA.3040503@redhat.com>
On Sat, Aug 21, 2010 at 07:40:10PM -0500, Eric Sandeen wrote:
> I'll send an xfstest but it'd be really great if could could work
> inside the xfstests framework when devising testcases...
If you could put together an xfstests, that would be great. I hadn't
because Mike's been trying to remind me that I really need to delegate
to others :-), and we do have someone at Google who can put the
xfstest script together. You can probably do it faster than he can,
though.
I didn't use xfs_io because I don't know how to use it, and because
it's not one of those things which is regularly on our production
machines that we use for testing. I probably start exploring all of
the things that can be done with it, though!
> Ted, is just checking for fs corruption is enough or do you think a
> test needs the debugfs stat inspection step? It'd be easy enough
> to special-case a debugfs step for ext4.
Well, if we end up suppressing the EOFBLOCKS_FL test e2fsck (which is
what we've already done as an emergency workaround) we can't count on
e2fsck detecting the problem, which is why I phrased this the way I
did for Aditya's benefit.
> > What I normally do is run it something like this:
> >
> > mount /scratch ; pushd /scratch; ~/testcase <opts>; popd ; umount /scratch ; debugfs /dev/sdc1 -R "stat test-file"
> >
> > What to look for is whether the flags field is either 0x480000 or
> > 0x80000. The 0x400000 flag is the EOFBLOCKS_FL flag. If last extent
> > is uninitialized, then the EOFBLOCKS_FL flag should be set.
>
> only if that last extent is past i_size, though...
Good point, and I guess I did have at least one test case where that
wasn't true.
- Ted
next prev parent reply other threads:[~2010-08-22 11:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-19 3:01 buggy EOFBLOCKS_FL handling Theodore Ts'o
2010-08-19 3:04 ` [PATCH, RFC] ext4: Fix " Theodore Ts'o
2010-08-21 21:07 ` [PATCH -v2] " Theodore Ts'o
2010-08-19 5:13 ` buggy " Andreas Dilger
2010-08-19 14:44 ` Ted Ts'o
2010-08-19 17:03 ` Eric Sandeen
2010-08-19 17:11 ` Ted Ts'o
2010-08-19 18:33 ` Andreas Dilger
2010-08-21 20:11 ` Updated test case Ted Ts'o
2010-08-22 0:40 ` Eric Sandeen
2010-08-22 11:42 ` Ted Ts'o [this message]
2010-08-22 15:35 ` Eric Sandeen
2010-08-23 18:05 ` Andreas Dilger
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=20100822114228.GB6329@thunk.org \
--to=tytso@mit.edu \
--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 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.