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.)
