linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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