On Mon, Oct 22, 2018 at 6:09 AM Jayashree Mohan <jayashree2912@xxxxxxxxx> wrote: > > On Sun, Oct 21, 2018 at 9:44 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > > > > > > > > See the file xfstests-dev/tests/generic/group to see how groups get > > > > > assigned to tests. I suppose all of the crashmonkey tests should be > > > > > assigned to a new group, say, "crashmonkey". > > > > Wait, let me get it straight. Did crashmonkey produce 300 test cases or > > did it find 300 bugs? Are all those test cases passing on all filesystems? > > Some test cases failing on some filesystems? > > CrashMonkey generates 300 workloads, out of which 3 tests result in > bugs in two file systems (btrfs and F2FS). So I suppose those 3 tests should be separate and mention the fix commit (if there is one?). > Others passed clean for > ext4, xfs, btrfs and F2FS. Given that xfstest is a regression test > suite, we thought it would be beneficial to add all 300 workloads to > the generic test - it is possible that a future kernel version has a > bug that could be triggered by one of these 300 workloads. We say so > because, these workloads test the file-system in a systematic manner > using common file-system operations. Given that crash-consistency > tests are sparse, checking a file system against these 300 workloads > will at least ensure that the file system is free from simple > crash-consistency bugs (in addition to testing for bugs that were > reported in earlier kernel versions). > Well, assuming your tests are quick, IMO auto quick fuzzer crash Is descriptive enough. Let's see what other people think. > > I suppose you don't HAVE to run all test cases on a fresh created fs?? > > so clean would be just rm -rf or even each test case could use its own > > subdir? > > You are right. A simple cleanup will work. We can club multiple of our > workloads into one test and create something like 1 test case per > file-system operation. > If that results in a "few" more "quick" tests, then I think its a good way to go. Thanks, Amir.
