On Thu, Dec 12, 2013 at 04:00:44PM -0800, Junho Ryu wrote: > > 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.... > > If it is acceptable that tmpfs running tests which does not make much > sense without actually re-mounting devices, all other developers need > to care is using _scratch_remount() and _test_remount(). And how are they to know whether it makes sense ot run on tmpfs or not? That's the point I'm trying to make - tmpfs adds new restrictions on how tests are written or constructed, and we still need a method of saying no to tmpfs.... > Even if someone does not use the functions, tests will only fail on > tmpfs, and people like me who cares about it will be happy to fix it. Yes, that's the game of whack-a-mole I was talking about. > So far, generic/053 is the only test which does something else between > umount and mount. All the generic tests that use dm_flakey are likely to be busted. Anything assumes SCRATCH_DEV or TEST_DEV are block devices are busted. Do loop devices work properly when hosted on tmpfs filesystems? And so on... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
