On Tue, Aug 18, 2015 at 09:07:52AM +1000, Dave Chinner wrote: > [cc fstests@xxxxxxxxxxxxxxx as we are talking about the test rather > than the kernel behaviour. ] > [snip] > > In all cases, ext3/305 reliably reproduced the failure within 30 > > mount/unmount cycles, and in most cases, under a dozen cycles. (i.e., > > under two seconds, and usually in a fraction of a second). So I'm not > > entirely sure why the test was written to run the loop for 3 minutes > > and thousands of mount/unmount cycles. > > There were lots of tests being written at the time that used a 3 > minute timeout. It's another of those red flags that I tend to > push back on these days, and this is an example of why - usually the > problem can be hit very quickly, or the test is extremely unreliable > and long runtime is the only way to trigger the race. Hence > running for X minutes doesn't really prove anything.... IIRC, 3 minutes time limit was based on my testing before I submitted the patch, but I could be wrong, it was two years ago.. I think I have better understanding of xfstests and regression tests now than two years ago, after years education on the list (mainly by Dave :-)) > > > Eryu, you wrote the test; any thoughts? At the very least I'd suggest > > cutting the test down so that it runs for at most 2 seconds, if for no > > other reason than to speed up regression test runs. > > Rather than time limiting, how about bounding the number of > mount/unmount cycles? Agreed, 30 cycles seem a reasonable number, I can prepare a patch if no objection. Thanks Ted and Dave for looking into this! Eryu -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
