On Fri, Mar 03, 2017 at 05:03:32PM +0800, Eryu Guan wrote: > On Thu, Mar 02, 2017 at 06:20:50PM -0500, Theodore Ts'o wrote: > > If the test device gets corrupted all subsequent tests will fail. To > > prevent this from causing all subsequent tests to be useless, try > > repair the file system on TEST_DEV if possible. We don't need to do > > this with the scratch device since that file system gets recreated > > each time anyway. > > > > Signed-off-by: Theodore Ts'o <tytso@xxxxxxx> > > --- > > > > This is a quick hack that I needed while debubgging some research > > code[1]. It turns out that when the grad student is up against a > > paper deadline is an, this becomes amazing evolutionary process which > > creates file system modifications which are optimized for running > > postmark and file bench --- and falls over very easily otherwise. So > > when TEST_DEV is getting corrupted very frequently, it's nice to be > > able to continue running other tests in the quick or auto group. > > > > So please consider this a proof-concept-patch; would people consider > > it worthwhile to have this in xfstests upstream? > > This idea looks reasonable to me, and TEST_DEV is supposed to be aging, > perhaps being currupted & repaired is kind of aging too :) <shrug> The test device isn't supposed to get corrupted, since it (at least in theory) should be an old filesystem. That said, I suppose there's little point in banging around with a corrupt test fs. Maybe we could go further and stop running if there's unfixable corruption? --D > > Thanks, > Eryu > -- > To unsubscribe from this list: send the line "unsubscribe fstests" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
