Re: [PATCH] fstest: CrashMonkey tests ported to xfstest

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Mon, Nov 05, 2018 at 02:16:57PM -0600, Jayashree Mohan wrote:
> 
> I believe that to _scratch_mkfs, I must first _cleanup dm_flakey. If I replace the above snippet by 
> _cleanup
> _scratch_mkfs
> _init_flakey
> 
> The time taken for the test goes up by around 10 seconds (due to mkfs maybe). So I thought it was sufficient to remove the working directory.

Can you try adding _check_scratch_fs after each test case?  Yes, it
will increase the test time, but it will make it easier for a
developer to figure out what might be going on.

Also, how big does the file system have to be?  I wonder if we can
speed things up if a ramdisk is used as the backing device for
dm-flakey.

On the flip side, am I remembering correctly that the original
technique used by your research paper used a custom I/O stack so you
could find potential problems even in the operations getting lost
after a power drop, no matter how unlikely, but rather, for anything
that isn't guaranteed by the cache flush command?

One argument for not using a ramdisk to speed things up is that it
would make be much less likely that potential problems would be found.
But I wonder, given that we're not using dm-flakey, how likely that we
would notice regressions in the first place.

For example, given that we know which patches were needed to fix the
various problems found by your research.  Suppose we revert those
patches, or use a kernel that doesn't have those fixes.  Will the
xfstests script you've generated be able to trigger the failures with
an unfixed kernel?

Cheers,

					- Ted