File system crash tests?
Snyder
like this: the tool writes something to the filesystem, and while
it does so, I pull the plug (physically). Then I power the system
back on, let the filesystem recover by whatever means it proposes
(replay the journal, run fsck, ...) and then the tool checks for
inconsistencies. Of course, it has to use some extra knowledge
for this; otherwise it would be as smart or dumb as the
filesystem itself (and its fsck, etc.).
André Gillibert
fsck -f (forced detailed check, even on FS with a journal) is the best tool you can find to check for inconsistencies. It might have bugs, but I doubt you can write a better program to check for consistency.
fsck, without -f, on journaled file systems, won't search for errors. It will simply replay the journal, assuming the file system is consistent, which may not be true of the file system journal logic is broken (buggy OS), or if unplugging the HD did subtly lost data it wasn't supposed to lose due to a firmware problem (e.g. the HD reported that its cache had been flushed while it wasn't completed) or a hardware problem. e.g. some blocks may be physically damaged if the head scratched the disk surface.
You may run badblocks -n to check for damaged blocks, and then, call fsck twice.
Once to replay the journal.
A second time with '-f' to check for file system consistency.
If you want to keep the normal boot procedure, the order will rather be:
fsck without -f (in the boot scripts).
And then
badblocks -n
fsck -f
By your scripts, when the system is booted.
This will only check file system consistency after journal replay, but won't give info on how much recent data may have been lost because it had not been written to disk when the machine is unplugged.
If you want to explore the software side only, you may use an hardware emulator. qemu or VirtualBox, for example.
--
André Gillibert.
Peter van Hooft
Perhaps you can use Elizabeth Zwicky's backup test suite.
It does interesting things to your filesystem...
Be prepared to lose your filesystem!
peter