Crash matrices and storage assumptions
What this concept is
A crash matrix enumerates failure cuts in a protocol and checks the surviving state against an independent expected outcome. Its coverage depends on the atomic steps and persistence rules you modeled. Enumerating every cut in a small model is not enumerating every failure of a real storage stack.
Why it matters here
A test that kills a process may leave kernel buffers and device caches intact. It therefore cannot alone validate a power-loss durability claim. Similarly, an atomic rename can protect visibility without proving that the renamed bytes and containing-directory entry are durable.
Concrete example
For three updates and five operations per update, the lab checks 16 cuts: before the first step and after each of 15 steps. Separately it checks nine byte-prefix lengths for two records. It assumes persisted prefixes and data checkpoints survive atomically and that earlier durable bytes are not lost.
Common confusion / misconception
Crash injection is not automatically realistic because it uses the word crash. The model omits reordered writes, torn data checkpoints, failed flushes and filesystem metadata. Successful model recovery cannot certify an SSD or filesystem; report exactly which assumptions make the result hold.
How to use it
Build expected state from protocol order, not by calling the recovery routine you are testing. For each cut, preserve durable log length, durable data, external acknowledgements and expected value. Recover, recover again, persist the recovered data, crash again and recover once more. Compare every result.
Check yourself
Why test recovery from a stale checkpoint and from an already-updated checkpoint? Both must converge. Why inspect fsync errors? A failed persistence operation cannot support a success promise. Why might the directory need its own persistence operation on Linux? Its naming metadata is separate from file data.
Mini drill or application
Add one new overwrite value and predict a cut after durable log but before acknowledgement. Propose a stronger failure model with one reordered or torn operation and explain which current proof step no longer holds.
Read this only if stuck
Return to OSTEP Files and Directories and the fsync documentation linked in the extension. Name the exact layer responsible for each durability claim.