All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Jayashree Mohan <jayashree2912@gmail.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
	Theodore Ts'o <tytso@mit.edu>, Eryu Guan <guaneryu@gmail.com>,
	Vijaychidambaram Velayudhan Pillai <vijay@cs.utexas.edu>,
	fstests <fstests@vger.kernel.org>
Subject: Re: Submitting patches to xfstests based on OSDI '18 paper (CrashMonkey)
Date: Mon, 22 Oct 2018 15:02:31 +1100	[thread overview]
Message-ID: <20181022040231.GN18822@dastard> (raw)
In-Reply-To: <CA+EzBbDdcJpupjPXnQZxcfQxqamwpc9TD0QJrvMOh6SSpy1Fyw@mail.gmail.com>

On Sun, Oct 21, 2018 at 10:23:06PM -0500, Jayashree Mohan wrote:
> On Sun, Oct 21, 2018 at 9:49 PM Amir Goldstein <amir73il@gmail.com> wrote:
> 
> > Wait, why _scratch_shutdown and not using dm_flakey?
> > Fewer filesystems support _scratch_shutdown and _scratch_shutdown
> > could be buggy and not simulate crash accurately.
> 
> Thanks for this note. I was looking at previous xfstest tests
> (something not very old - generic/468 for eg), and it was using
> scratch_shutdown. Hence I used that as an example. I'll use
> flakey_drop_and_remount while writing up future patches.
> 
> Doesn't this mean the current tests in xfstest suite might miss bugs
> in current/future kernel versions, because some file systems don't
> support it?

scratch_shutdown is testing shutdown behaviour, whatever the cause.
Not all filesystems have a shutdown mechanism - it's a specific set
of operations that the filesystem performs in response to failure
triggers. Some filesystems just go read-only or have other response
mechanisms, which aren't compatible with expected shutdown
behaviour.

And because shutdowns can be caused by things other than IO errors
(which dm-flakey triggers) and so need to be tested /in addition/ to
other types of failures.

> There are many crash-consistency tests in xfstest suite
> that still use _scratch_shutdown.

Yes, because shutdowns can /simulate/ such failures.

> In fact generic/468 is one of the
> test cases that could not run on btrfs because it does not support
> _shutdown.

Yes, but that doesn't stop us from having the test. If btrfs were to
implement a shutdown mechanism, then they'd gain coverage from these
tests too.

> But then this is the exact test case required to reveal a
> bug in btrfs - where you lose allocated blocks beyond the eof on
> fallocate. Just wanted to bring this up, in case you did not notice it

Then add support for shutdowns to btrfs, and it will get test
coverage from these tests. That's not a problem with the test -
that's a filesystem functionality deficiency. i.e. fix the
filesystem, don't change the test.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-10-22 12:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-15 20:58 Submitting patches to xfstests based on OSDI '18 paper (CrashMonkey) Jayashree Mohan
2018-10-21 10:45 ` Eryu Guan
2018-10-21 15:53   ` Jayashree Mohan
     [not found]   ` <CA+EzBbCd2zZ9sNW-dgyPyR5FH-HK5LArG6y+bPOCJ3Wqyp5=Ug@mail.gmail.com>
2018-10-21 22:21     ` Theodore Y. Ts'o
2018-10-21 22:52       ` Jayashree Mohan
2018-10-22  2:05         ` Dave Chinner
2018-10-22  2:35           ` Jayashree Mohan
2018-10-22  2:49             ` Amir Goldstein
2018-10-22  3:23               ` Jayashree Mohan
2018-10-22  4:02                 ` Dave Chinner [this message]
2018-10-22  7:14                   ` Theodore Y. Ts'o
2018-10-22  4:23                 ` Amir Goldstein
2018-10-22  2:44           ` Amir Goldstein
2018-10-22  3:09             ` Jayashree Mohan
2018-10-22  3:47               ` Amir Goldstein
2018-10-22  4:15               ` Dave Chinner
2018-10-22 13:25                 ` Eric Sandeen
2018-10-22 23:18                 ` Jayashree Mohan

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=20181022040231.GN18822@dastard \
    --to=david@fromorbit.com \
    --cc=amir73il@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=guaneryu@gmail.com \
    --cc=jayashree2912@gmail.com \
    --cc=tytso@mit.edu \
    --cc=vijay@cs.utexas.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 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.