From: Shentino <shentino@gmail.com>
To: dave@jikos.cz, Shentino <shentino@gmail.com>,
Michael <mike@draftx.net>, cwillu <cwillu@cwillu.com>,
linux-btrfs@vger.kernel.org
Subject: Re: rfc: fuzz testing by direct writes to device
Date: Sun, 2 Sep 2012 04:43:48 -0700 [thread overview]
Message-ID: <CAGDaZ_r1zZWGh5riLnNnZR8raZZQNwSe0qSNgY3BaBWN-A9Fbg@mail.gmail.com> (raw)
In-Reply-To: <20120902054410.GG17430@twin.jikos.cz>
On Sat, Sep 1, 2012 at 10:44 PM, David Sterba <dave@jikos.cz> wrote:
> On Sat, Sep 01, 2012 at 06:03:32PM -0700, Shentino wrote:
>> This whole subject was also about using sed to corrupt-o-magic a
>> file's data on disk.
>>
>> Is this an acceptable method for testing?
>
> Starting with kernels 3.4 the error handling has been improved,
> namely for the EIO, so it shouldn't take your box down when you hit one.
> Newer kernels got fixes to the 'transaction abort' cleanup, so it should
> be possible to umount and mount the filesystem without problems.
>
> The filesystem should survive shooting at blocks, the checksums catch
> any change (with respect to it's strength, ie. generating a hash
> collision will lead to crash/abort later).
>
> Expected result for reading blocks after random writes is:
> * EIO for the corrupted block (both data or metadata) provided that
> there's no other copy
> * transparent and automatic repair from other copies
I assume the same results are expected during a scrub as during a normal read?
> I've tested this on an 2 disk data/raid1, metadata/raid1 with a running
> dd over one of the devices continually and using the filesystem. It was
> slower.
>
>
> david
Would I be correct to assume that a core dump on fsck is an automatic
bug or is using the old 3.3.8 kernel a taint that would invalidate a
report? Note that this is for the btrfs-progs containing the fsck,
not the actual kernel side code.
next prev parent reply other threads:[~2012-09-02 11:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-01 6:44 rfc: fuzz testing by direct writes to device Shentino
2012-09-01 8:10 ` Shentino
2012-09-01 15:41 ` Michael
2012-09-01 17:23 ` Shentino
2012-09-01 20:59 ` cwillu
2012-09-01 22:31 ` Shentino
2012-09-01 23:49 ` Michael
2012-09-02 1:03 ` Shentino
2012-09-02 5:44 ` David Sterba
2012-09-02 11:43 ` Shentino [this message]
2012-09-05 15:04 ` David Sterba
2012-09-05 21:23 ` Shentino
2012-09-04 18:15 ` Goffredo Baroncelli
2012-09-05 1:59 ` Shentino
2012-09-05 5:46 ` Goffredo Baroncelli
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=CAGDaZ_r1zZWGh5riLnNnZR8raZZQNwSe0qSNgY3BaBWN-A9Fbg@mail.gmail.com \
--to=shentino@gmail.com \
--cc=cwillu@cwillu.com \
--cc=dave@jikos.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=mike@draftx.net \
/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).