linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Kalpak Shah <kalpak@clusterfs.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: Random corruption test for e2fsck
Date: Tue, 10 Jul 2007 10:58:55 -0400	[thread overview]
Message-ID: <20070710145855.GB27033@thunk.org> (raw)
In-Reply-To: <1184072860.4440.39.camel@garfield.linsyssoft.com>

On Tue, Jul 10, 2007 at 06:37:40PM +0530, Kalpak Shah wrote:
> Hi,
> 
> This is a random corruption test which can be included in the e2fsprogs
> regression tests. 
> 1) Create an test fs and format it with ext2/3/4 and random selection of
> features.
> 2) Mount it and copy data into it.

This requires root privileges in order to mount the loop filesystem.
Any chance you could change it to use debugfs to populate the
filesystem, so we don't need root privs in order to mount it.

This will increase the number of people that will actually run the
test, and more importantly not encourage people from running "make
check" as root.

> 3) Move around the blocks of the filesystem randomly causing corruption.
> Also overwrite some random blocks with garbage from /dev/urandom. Create
> a copy of this corrupted filesystem.
>
> 4) Unmount and run e2fsck. If the first run of e2fsck produces any
> errors like uncorrected errors, library error, segfault, usage error,
> etc. then it is deemed a bug. But in any case, a second run of e2fsck is
> done to check if it renders the filesystem clean. 

Err, you do unmount the filesystem first before you start corrupting
it, right?  (Checking script; sure looks like it.)

> 5) If the test went by without any errors the test image is deleted and
> in case of any errors the user is notified that the log of this test run
> should be mailed to linux-ext4@ and the image should be preserved.

I certainly like the general concept!!

I wonder if the code to create a random filesystem and corrupting it
should be kept as separate shell script, since it can be reused in
another of interesting ways.  One thought would be to write a test
script that mounts corrupted filesystems using UML and then does some
exercises on it (tar cvf on the filesyste, random renames on the
filesystem, rm -rf of all of the contents of the filesystems), to see
whether we can provoke a kernel oops.

Regards,

							- Ted

  reply	other threads:[~2007-07-10 14:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-10 13:07 Random corruption test for e2fsck Kalpak Shah
2007-07-10 14:58 ` Theodore Tso [this message]
2007-07-10 15:42   ` Eric Sandeen
2007-07-11  7:03   ` Kalpak Shah
     [not found]   ` <20070711094410.GM6417@schatzie.adilger.int>
2007-07-11 17:43     ` Theodore Tso
2007-07-12  5:15       ` Andreas Dilger
2007-07-12  5:52   ` Andreas Dilger
2007-07-10 15:47 ` Eric Sandeen
2007-07-11 16:03   ` Andreas Dilger
2007-07-11 15:20 ` Andi Kleen
2007-07-12  5:19   ` Andreas Dilger
2007-07-12 11:09     ` Andi Kleen
2007-07-12 22:16       ` Andreas Dilger
2007-07-12 22:24         ` Andi Kleen
2007-07-13  7:12           ` Kalpak Shah

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=20070710145855.GB27033@thunk.org \
    --to=tytso@mit.edu \
    --cc=kalpak@clusterfs.com \
    --cc=linux-ext4@vger.kernel.org \
    /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).