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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
