hesela.devCrash-corruption ambiguity
Crash-corruption ambiguity occurs when the same observed stored state is consistent with both an interrupted update and corruption after persistence.
A mismatched log entry and a present integrity record can leave the cause unresolved when their writes were not ordered. Recovery needs protocol evidence before treating acknowledged data as expendable. [1]
A constructed one-byte example leaves exactly the same bytes after two different histories: the new digest persists without the payload, or both persist and the payload later changes. Detecting a mismatch does not identify the history. [2]
Relations
- related
- journal-checksum, crash-consistency, checksum, write-ahead-log, torn-write
Citations
- Alagappan et al., Protocol-Aware Recovery for Consensus-Based Storage, FAST 2018, section 3.3.3
- Hesela: Ext4 replay, checksum failure paths and ambiguous tails
Sources & caveats
- The paper's protocol model and Hesela's constructed byte example are not present-day field failure measurements.