From: David Sterba <dsterba@suse.cz>
To: Dave Chinner <david@fromorbit.com>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>,
fstests@vger.kernel.org, btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Is is possible to submit binary image as fstest test case?
Date: Fri, 7 Oct 2016 18:05:51 +0200 [thread overview]
Message-ID: <20161007160551.GD11398@twin.jikos.cz> (raw)
In-Reply-To: <20161007091838.GG9806@dastard>
On Fri, Oct 07, 2016 at 08:18:38PM +1100, Dave Chinner wrote:
> On Thu, Oct 06, 2016 at 04:12:56PM +0800, Qu Wenruo wrote:
> > Hi,
> >
> > Just as the title says, for some case(OK, btrfs again) we need to
> > catch a file system in special timing.
> >
> > In this specific case, we need to grab a btrfs image undergoing
> > balancing, just before the balance finished.
> >
> > Although we can use flakey to drop all write, we still don't have
> > method to catch the timing of the that transaction.
> >
> >
> > On the other hand, we can tweak our local kernel, adding
> > msleep()/message and dump the disk during the sleep.
> > And the image I dumped can easily trigger btrfs kernel and user-space bug.
> >
> > So I'm wondering if I can just upload a zipped raw image as part of
> > the test case?
>
> Preferably not. We've managed to avoid pre-built images in xfstests
> for 15 years, so there'd have to be a really good reason to start
> doing this, especially as once we open that floodgate we'll end up
> with everyone wanting to do this and it will blow out the size of
> the repository in now time.
>
> If the issue is just timing or being unable to trigger an error
> at the right time, this is what error injection frameworks or
> debug-only sysfs hooks are for. The XFS kernel code has both,
> xfstests use both, and they pretty much do away with the need for
> custom binary filesystem images for such testing...
Error injection framework may not be alwasy available, eg. in kernels
built for production. Yet I'd like to make the test possible.
Also, I find it useful to keep the exact images that are attached to a
report and not necessarily try to recreate it to trigger a bug. If the
images are small, hosting them with the sources makes testing easy.
Big images would probably go to own repository and be linked.
I don't really expect fstests to store crafted images and would advise
Qu to not even try to propose that, because the answer was quite
predictable.
next prev parent reply other threads:[~2016-10-07 16:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-06 8:12 Is is possible to submit binary image as fstest test case? Qu Wenruo
2016-10-06 8:12 ` Qu Wenruo
2016-10-06 12:29 ` Brian Foster
2016-10-06 19:24 ` Theodore Ts'o
2016-10-07 15:51 ` David Sterba
2016-10-07 9:18 ` Dave Chinner
2016-10-07 9:26 ` Qu Wenruo
2016-10-07 9:26 ` Qu Wenruo
2016-10-07 10:19 ` Dave Chinner
2016-10-07 16:16 ` David Sterba
2016-10-08 3:28 ` Qu Wenruo
2016-10-07 16:05 ` David Sterba [this message]
2016-10-09 23:56 ` Dave Chinner
2016-10-14 18:11 ` 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=20161007160551.GD11398@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.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.