All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eryu Guan <guaneryu@gmail.com>
To: Jayashree Mohan <jayashree2912@gmail.com>
Cc: Filipe Manana <fdmanana@gmail.com>,
	fstests <fstests@vger.kernel.org>,
	Vijaychidambaram Velayudhan Pillai <vijay@cs.utexas.edu>,
	Theodore Ts'o <tytso@mit.edu>, Dave Chinner <david@fromorbit.com>,
	Amir Goldstein <amir73il@gmail.com>
Subject: Re: [PATCH] fstest: CrashMonkey tests ported to xfstest
Date: Sun, 4 Nov 2018 08:27:16 -0800 (PST)	[thread overview]
Message-ID: <20181104162716.GG12788@desktop> (raw)
In-Reply-To: <CA+EzBbDZ0NY--5f4FQv2MuRLyKoXiuMEa6UhnFJ+RsAF1d0gmg@mail.gmail.com>

On Fri, Nov 02, 2018 at 03:39:51PM -0500, Jayashree Mohan wrote:
> Hi Filipe,
> 
> Thanks for the feedback on the patch. Will fix the coding style as you
> suggested.
> 
> > For this type of tests, I think it's a good idea to let fsck run.
> >
> > Even if all of the links are persisted, the log/journal replay might
> > have caused metadata inconsistencies in the fs for example - this was
> > true for many cases I fixed over the years in btrfs.
> > Even if fsck doesn't report any problem now, it's still good to run
> > it, to help prevent future regressions.
> >
> > Plus this test creates a very small fs, it's not like fsck will take a
> > significant time to run.
> > So for all these reasons I would unmount and fsck after each test.

This looks reasonable to me.

> 
> Originally, there are 300 odd crash-consistency tests generated by
> CrashMonkey. To run fsck after each test, we will have to convert each
> of these tests into an equivalent xfstest test-case. We previously had
> a discussion about this, on the thread here (
> https://www.spinics.net/lists/fstests/msg10718.html ) and the
> suggestion was to batch similar tests together to reduce the external
> per-test overhead due to scrub/fsck.

You could batch similar tests together but still do fsck after each
sub-test by calling _check_scratch_fs manually, and call
_require_scratch_nocheck to indicate there's no need to do fsck at the
end of test.

> Additionally, batching similar tests will result in around 15 new test
> cases that could be added to the 'quick group', as opposed to adding
> 300 new tests.

I think we could batch similar tests and create relatively small fs
(e.g. 256M, as btrfs defaults to mixed mode if fs < 256M, and btrfs
folks wanted to test non-mixed mode by default) and run fsck after each
sub-test first, then see how long the tests take.

Thanks,
Eryu

> 
> However, if you still recommend that fsck be run after each test, I
> can submit patches for 300 individual test cases. Let me know which
> one is preferable.
> 
> Thanks,
> Jayashree.

  reply	other threads:[~2018-11-05  1:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-29 16:50 [PATCH] fstest: CrashMonkey tests ported to xfstest Jayashree Mohan
2018-10-30 13:05 ` Filipe Manana
2018-11-02 20:39   ` Jayashree Mohan
2018-11-04 16:27     ` Eryu Guan [this message]
2018-11-04 16:38 ` Eryu Guan
2018-11-04 20:21   ` Jayashree Mohan
2018-11-05  5:22     ` Dave Chinner
2018-11-05 20:16       ` Jayashree Mohan
2018-11-06 22:57         ` Dave Chinner
2018-11-06 23:15         ` Theodore Y. Ts'o
2018-11-06 23:39           ` Dave Chinner
     [not found]             ` <CA+EzBbDwdi26MCswz0iQ8hUTcGixATUXayxMOmEw5gekYvmMuw@mail.gmail.com>
     [not found]               ` <5be228d2.1c69fb81.3ad08.5e76.GMR@mx.google.com>
2018-11-06 23:54                 ` Delivery Status Notification (Failure) Jayashree Mohan
2018-11-07  2:09               ` [PATCH] fstest: CrashMonkey tests ported to xfstest Dave Chinner
2018-11-07  4:04                 ` Theodore Y. Ts'o
2018-11-08  1:41                   ` Jayashree Mohan
2018-11-08  9:10                     ` Dave Chinner
2018-11-08 14:46                       ` Jayashree Mohan
2018-11-08  9:40                 ` Dave Chinner
2018-11-08 15:35                   ` Vijaychidambaram Velayudhan Pillai
2018-11-09  3:12                     ` Dave Chinner
2018-11-09 16:39                       ` Vijaychidambaram Velayudhan Pillai
2018-11-09 19:17                         ` Theodore Y. Ts'o
2018-11-09 20:47                           ` Vijaychidambaram Velayudhan Pillai
2018-11-08 16:10                   ` Theodore Y. Ts'o
2018-11-07  0:24           ` 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=20181104162716.GG12788@desktop \
    --to=guaneryu@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=david@fromorbit.com \
    --cc=fdmanana@gmail.com \
    --cc=fstests@vger.kernel.org \
    --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.