From: Josef Bacik <josef@toxicpanda.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 0/3] Handle bad dev_root properly with rescue=all
Date: Thu, 18 Mar 2021 16:45:01 -0400 [thread overview]
Message-ID: <80e729e7-8fc5-d083-0640-7eedc7b96b6b@toxicpanda.com> (raw)
In-Reply-To: <20210318154351.GX7604@twin.jikos.cz>
On 3/18/21 11:43 AM, David Sterba wrote:
> On Thu, Mar 11, 2021 at 11:23:13AM -0500, Josef Bacik wrote:
> [...]
>
>> rescue=all working without panicing the machine,
>> and I verified everything by
>> using btrfs-corrupt-block to corrupt a dev root of a file system. Thanks,
>
> We need to have such testing part of some suite but it depends on the
> utilities that we don't want to ship by default. Last time we discussed
> how to make btrfs-corrupt-block or similar available in source form in
> fstests it was not pretty, like having half of the btrfs-progs sources
> providing code to read and modify the data structures.
>
> So, what if: we have such tests in the btrfs-progs testsuite. As they're
> potentially dangerous, not run by default, but available for easy setup
> and test in a VM. The testsuite can be exported into a tarball, with the
> binaries included. Or simply run it built from git, that works too just
> needs more dependencies installed.
>
> I was thinking about collecting all the stress tests into one place,
> fstests already has some but my idea is to provide stress testing of
> btrfs-specific features, more at once. Or require some 3rd party tools
> and data sources to provide the load.
>
> It would be some infrastructure duplication with fstests, but lots of
> that is already done in btrfs-progs and I'd rather go with some
> duplication instead of development-time-only testing.
>
I actually had Boris working on this, basically allow us to set
BTRFS_CORRUPT_PROG inside our fstests config, and then allow us to write these
tests for fstests. I'd prefer to keep this inside xfstests for mostly selfish
reasons, it's easier for me to adapt the existing continual testing to take
advantage of this and automatically run the xfstests stuff and post the results.
If we keep it in btrfs-progs I have to write a bunch of code to run those to
post the results to our continual testing stuff. Thanks,
Josef
prev parent reply other threads:[~2021-03-18 20:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 16:23 [PATCH 0/3] Handle bad dev_root properly with rescue=all Josef Bacik
2021-03-11 16:23 ` [PATCH 1/3] btrfs: init devices always Josef Bacik
2021-03-12 5:52 ` Anand Jain
2021-03-12 5:57 ` Anand Jain
2021-03-17 11:03 ` David Sterba
2021-03-12 5:58 ` Anand Jain
2021-03-11 16:23 ` [PATCH 2/3] btrfs: do not init dev stats if we have no dev_root Josef Bacik
2021-03-12 5:59 ` Anand Jain
2021-03-11 16:23 ` [PATCH 3/3] btrfs: don't init dev replace for bad dev root Josef Bacik
2021-03-12 6:50 ` Anand Jain
2021-03-11 19:18 ` [PATCH 0/3] Handle bad dev_root properly with rescue=all Neal Gompa
2021-03-17 12:27 ` David Sterba
2021-03-17 15:30 ` Josef Bacik
2021-03-18 15:43 ` David Sterba
2021-03-18 20:45 ` Josef Bacik [this message]
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=80e729e7-8fc5-d083-0640-7eedc7b96b6b@toxicpanda.com \
--to=josef@toxicpanda.com \
--cc=dsterba@suse.cz \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@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