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
|