From: "Jérôme Carretero" <cJ-ko@zougloub.eu>
To: linux-btrfs@vger.kernel.org
Cc: Nageswara R Sastry <rnsastry@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, chris.mason@oracle.com,
kamalesh@linux.vnet.ibm.com, Liu Bo <liubo2009@cn.fujitsu.com>
Subject: Re: [BUG] Kernel Bug at fs/btrfs/volumes.c:3638
Date: Sun, 26 Feb 2012 23:42:58 -0500 [thread overview]
Message-ID: <20120226234258.522ee56e@Bidule> (raw)
In-Reply-To: <4F476959.2010400@linux.vnet.ibm.com>
On Fri, 24 Feb 2012 16:11:29 +0530
Nageswara R Sastry <rnsastry@linux.vnet.ibm.com> wrote:
> Hello,
>
> While working with 'fsfuzz - file system fuzzing tool' on 'btrfs'
> encountered the following kernel bug.
I inquired about robustness a while ago and it seems it's at some point on the horizon, but not now.
My concern was about hot-unplugged disk drives, but btrfs also doesn't appreciate meta-data corruption.
btrfs-raid users could be concerned, because contrarily to on a real RAID, the btrfs meta-data is a potential weak link.
At some point, I would appreciate some kind of thorough evaluation using a fuzzer on small disk images.
The btrfs developers could for instance:
- provide a script to create a filesystem image with a known layout (known corpus)
- provide .config and reference to kernel sources to build the kernel
- provide a minimal root filesystem to be run under qemu, it would run a procedure on the other disk image at boot
crashes wouldn't affect the host, which is good.
- provide a way to retrieve the test parameters and results for every test case
in case of bug, the test can be reproduced by the developers since the configuration is known
- expect volunteers to run the scenarios (I know I would)
The tricky part is of course the potentially super-costly procedure...
Simplest case: flipping every bit / writing blocks with pseudo-random data, even on meta-data only, as the outcome on data is supposed to be known.
Smarter: flipping bits on every btrfs meta-data structure type at every possible logical location.
The kind of stuff that would help all this could be something like Python bindings for a *btrfs library*.
Helpful even for prototyping fsck stuff, making illustrations, etc.
As of today, how are btrfs developers testing the filesystem implementation (except with xfstests) ?
Best regards,
--
cJ
PS: don't be mistaken, I'm not asking for all that, just suggesting.
My time goes to something else, but I do have sleepy computers at home, and they could help.
next prev parent reply other threads:[~2012-02-27 4:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-24 10:41 [BUG] Kernel Bug at fs/btrfs/volumes.c:3638 Nageswara R Sastry
2012-02-25 6:12 ` Liu Bo
2012-02-27 5:56 ` Nageswara R Sastry
2012-02-27 5:56 ` Nageswara R Sastry
2012-02-27 4:42 ` Jérôme Carretero [this message]
2012-02-27 14:52 ` David Sterba
2012-02-27 14:52 ` David Sterba
2012-03-01 0:27 ` David Sterba
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=20120226234258.522ee56e@Bidule \
--to=cj-ko@zougloub.eu \
--cc=chris.mason@oracle.com \
--cc=kamalesh@linux.vnet.ibm.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liubo2009@cn.fujitsu.com \
--cc=rnsastry@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.