On Fri, Nov 30, 2012 at 10:08:46AM -0600, Eric Sandeen wrote: > On 11/30/12 10:06 AM, Christoph Hellwig wrote: > > On Thu, Nov 29, 2012 at 12:59:55PM -0600, Eric Sandeen wrote: > >> This will cause the $SCRATCH_DEV to be fscked if it was used in > >> the prior test. Without this I don't think it gets done unless > >> specifically requested by the test. > > > > This one looks good. > > Hm now that I think of it perhaps I should remove the explicit > _check_scratch-es if they happen at the end of the run, just to > try to speed things up. *nod* > >> Also recreate lost+found/ in one test so that e2fsck doesn't > >> complain. > > > > This one I can't make any sense of. Care to send it separately > > with a good explanation? > > > > Ok, sure. > > Basically, test does an rm -rf of the scrach mnt, but e2fsck > thinks that a missing lost+found/ is cause for complaint and a > failure exit code, which then stops the tests :( Shouldn't e2fsck be fixed? i.e. if you have a corrupted filesystem and it's missing lost+found, how are you expected to create it? by mounting your corrupted filesystem and modifying it and potentially making the corruption worse? > (hum, now that I think about it, maybe a broken scratch device > shouldn't stop the test series, but should just log a test > failure? What do you think?) Stop it - we should be leaving a corpse that we can dissect to find out what went wrong. For a corrupted scratch filesystem, running another test will eat the slowly rotting corpse and leave nothing useful behind for diagnosing the failure... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
