From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: tytso@mit.edu, Junho Ryu <jayr@google.com>,
hughd@google.com, xfs@oss.sgi.com,
Christoph Hellwig <hch@infradead.org>,
branto@redhat.com
Subject: Re: [PATCH 05/10] xfstests: do not unmount tmpfs during remount.
Date: Fri, 13 Dec 2013 03:04:07 -0800 [thread overview]
Message-ID: <20131213110407.GB14884@infradead.org> (raw)
In-Reply-To: <20131212225657.GK10988@dastard>
On Fri, Dec 13, 2013 at 09:56:57AM +1100, Dave Chinner wrote:
> Yes, but that's not the same situation as tmpfs here. A generic
> filesystem fits a certain model but the given configuration/kernel
> does not necessarily support the feature being tested. Those
> features are easily testable by a _requires_* line.
>
> This case with tmpfs is different - it doesn't support *being
> unmounted* during a test because it is volatile. That's a
> fundamental change to the assumptions xfstests makes about
> filesystems being tested. IOWs, we've got a "generic" filesystem
> that is anything but generic.
It's not really a fundamental change for tests supposed to be run on
the TEST_DIR fs. In fact I'd go so far to say that one patch that
unmounts and repairs it manually should switch to the scratch fs.
Running the scratch tests on tmpfs is a bit more fragile, but I don't
really see a big problem with the concept.
> Adding "_requires_non_volatile_fs" to all the generic tests that do
> an unmount so that tmpfs can be considered "generic" is just as
> painful as modifying the "_supported_fs generic" lines in all the
> tests. It just leads us to a game of whack-a-mole.
What's the problem? It's not that bad if you look at the series, and
as long as someone maintains tmpfs support it shouldn't burden anyone
else. If it stops being maintained we can drop the support after a
while. Then again we still have utterly bitrotted IRIX support around..
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-12-13 11:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-10 20:11 [PATCH 00/10] Add tmpfs filesystem support Junho Ryu
2013-12-10 20:11 ` [PATCH 01/10] xfstests: Add tmpfs support Junho Ryu
2013-12-11 7:40 ` Christoph Hellwig
2013-12-17 16:40 ` Rich Johnston
2013-12-10 20:11 ` [PATCH 02/10] xfstests: use mount point instead of device name Junho Ryu
2013-12-11 7:42 ` Christoph Hellwig
2013-12-10 20:11 ` [PATCH 03/10] xfstests: _scratch_mkfs_sized() for tmpfs Junho Ryu
2013-12-11 7:44 ` Christoph Hellwig
2013-12-10 20:11 ` [PATCH 04/10] xfstests: increase tmpfs memory size Junho Ryu
2013-12-11 7:44 ` Christoph Hellwig
2013-12-10 20:11 ` [PATCH 05/10] xfstests: do not unmount tmpfs during remount Junho Ryu
2013-12-11 7:46 ` Christoph Hellwig
2013-12-11 22:40 ` Dave Chinner
2013-12-12 0:16 ` Theodore Ts'o
2013-12-12 0:53 ` Dave Chinner
2013-12-12 18:01 ` Christoph Hellwig
2013-12-12 22:56 ` Dave Chinner
2013-12-13 0:00 ` Junho Ryu
2013-12-13 1:41 ` Dave Chinner
2013-12-13 11:12 ` Christoph Hellwig
2013-12-13 4:56 ` Theodore Ts'o
2013-12-13 11:04 ` Christoph Hellwig [this message]
2013-12-10 20:11 ` [PATCH 06/10] xfstests: fix generic/225 to check fiemap support Junho Ryu
2013-12-11 7:46 ` Christoph Hellwig
2013-12-11 22:42 ` Dave Chinner
2013-12-12 18:01 ` Christoph Hellwig
2013-12-12 22:44 ` Junho Ryu
2013-12-12 23:00 ` Dave Chinner
2013-12-10 20:11 ` [PATCH 07/10] xfstests: fix generic/127 to call _cleanup() only once Junho Ryu
2013-12-11 7:47 ` Christoph Hellwig
2013-12-10 20:11 ` [PATCH 08/10] xfstests: check O_DIRECT support before testing direct I/O Junho Ryu
2013-12-11 7:47 ` Christoph Hellwig
2013-12-10 20:12 ` [PATCH 09/10] xfstests: add executable permission to tests Junho Ryu
2013-12-11 7:48 ` Christoph Hellwig
2013-12-10 20:12 ` [PATCH 10/10] xfstests: skip parts of tests which cannot work on tmpfs Junho Ryu
2013-12-11 7:51 ` Christoph Hellwig
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=20131213110407.GB14884@infradead.org \
--to=hch@infradead.org \
--cc=branto@redhat.com \
--cc=david@fromorbit.com \
--cc=hughd@google.com \
--cc=jayr@google.com \
--cc=tytso@mit.edu \
--cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox