Re: Submitting patches to xfstests based on OSDI '18 paper (CrashMonkey)

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

On Mon, Oct 22, 2018 at 03:02:31PM +1100, Dave Chinner wrote:
> scratch_shutdown is testing shutdown behaviour, whatever the cause.
> Not all filesystems have a shutdown mechanism - it's a specific set
> of operations that the filesystem performs in response to failure
> triggers. Some filesystems just go read-only or have other response
> mechanisms, which aren't compatible with expectetd shutdown
> behaviour.

What Dave said.

I'll note that at the moment ext4 passes dm_flakey power cut tests
reliably, which is *different* from the tests which use the
FS_IOC_SHUTDOWN ioctl.  At the moment ext4, fails FS_IOC_SHUTDOWN
tests around 3% -- 5% of the time --- which is why generic/388, which
repeatedly mounts and call FS_IOC_SHUTDOWN 30 times, is a flaky
(sorry) test for ext4.

So for the crashmonkey tests, if you are specifically trying to test
what happens on a power cut, you need to be using dm_flakey, and not
FS_IOC_SHUTDOWN.  Testing what happens on FS_IOC_SHUTDOWN would also
be useful, but it's a different thing.  (And at least for ext4, I know
what the problems are with ext4's FS_IOC_SHUTDOWN support; the
challenge is how to fix it without imposing a performance regression,
and since FS_IOC_SHUTDOWN is rarely used in production[1], it's been
low priority for me to fix.)

						- Ted

[1] Actually, Google does use FS_IOC_SHUTDOWN in production, but only
for scratch iSCSI volumes which have already disappeared and so we
don't care if the underlying file system might get corrupted, since
the whole point is to forcibly detach the failed iSCSI device while
keeping the iSCSI client system running.  (And since it's a scratch
volume, it's mounted with the journal disabled, which means on
shutdown, even we cared about the state of the scratch volume after
shutdown, by in no journal mode there are no guarantees about file
system consistency after a shutdown or power cut anyway.)