From: Eric Sandeen <sandeen@redhat.com>
To: Kalpak Shah <kalpak@clusterfs.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>, TheodoreTso <tytso@mit.edu>
Subject: Re: Random corruption test for e2fsck
Date: Tue, 10 Jul 2007 10:47:06 -0500 [thread overview]
Message-ID: <4693A9FA.7040106@redhat.com> (raw)
In-Reply-To: <1184072860.4440.39.camel@garfield.linsyssoft.com>
Kalpak Shah wrote:
> Hi,
>
> This is a random corruption test which can be included in the e2fsprogs
> regression tests. It does the following:
> 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.
> 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.
> 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.
>
> Any comments are welcome.
Seems like a pretty good idea. I had played with such a thing using
fsfuzzer... fsfuzzer always seemed at least as useful useful as a fsck
tester than a kernel code tester anyway. (OOC, did you look at fsfuzzer
when you did this?)
My only concern is that since it's introducing random corruption, new
things will probably pop up from time to time; when we do an rpm build
for Fedora/RHEL, it automatically runs make check:
%check
make check
which seems like a reasonably good idea to me. However, I'd rather not
have last-minute build failures introduced by new random collection of
bits that have never been seen before. Maybe "make RANDOM=0 check" as
an option would be a good idea for automated builds...?
Thanks,
-Eric
next prev parent reply other threads:[~2007-07-10 15:50 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
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 [this message]
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=4693A9FA.7040106@redhat.com \
--to=sandeen@redhat.com \
--cc=kalpak@clusterfs.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 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).