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 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).