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...