Re: [PATCH 05/10] xfstests: do not unmount tmpfs during remount.

[Theodore Ts'o <tytso@mit.edu>]

On Fri, Dec 13, 2013 at 09:56:57AM +1100, Dave Chinner wrote:
> 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....
> 
> I don't know what the solution here is - everything I think of is
> either messy, ugly or unmaintainable. All I'm trying to do is find a
> way to handle tmpfs filesystems in a way that is maintainable and
> doesn't require every developer to be aware of the quirks of tmpfs
> when writing and reviewing new generic tests....

There should be a relatively small number of reasons why a generic
test would need to umount and remount a file system; the most common
case is so it can run fsck on the file system.

What's actually strange is that is that generic/053 is explicitly
umounting and remounting the file system:

_do 'unmount $SCRATCH_DEV' 'umount $SCRATCH_DEV'
_do 'repair filesystem' '_check_scratch_fs'
_do 'mount filesytem' '_scratch_mount'

In fact, that's not necessary, because _check_test_fs and
_check_scratch_fs will take care of umounting and remounting the file
system.  So if this is the only problem case which Junho has found,
why not just patch generic/053 so it doesn't explicitly umount and
remount the file system, since we've already taught _check_*_fs to be
a no-op for tmpfs.

As for dm_flakey, tests, we can just have _require_dm_flaky be false
for tmpfs file system.

So we're still playing whack-a-mole, yes, but on classes of test
requirements instead of individual tests.  If we address the
umount/remount for fsck and dm_flakey, are there other significant
classes of tests that would still be problematic for tmpfs?

						- Ted

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs