{
  "slug": "crash-corruption-ambiguity",
  "term": "Crash-corruption ambiguity",
  "aliases": [
    "Crash-corruption entanglement"
  ],
  "definition": "Crash-corruption ambiguity occurs when the same observed stored state is consistent with both an interrupted update and corruption after persistence.",
  "note": "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. [par]\n\nA 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. [hesela]",
  "status": "research",
  "advantages": [],
  "limitations": [],
  "related": [
    "journal-checksum",
    "crash-consistency",
    "checksum",
    "write-ahead-log",
    "torn-write"
  ],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "citations": [
    {
      "id": "par",
      "title": "Alagappan et al., Protocol-Aware Recovery for Consensus-Based Storage, FAST 2018, section 3.3.3",
      "url": "https://www.usenix.org/system/files/conference/fast18/fast18-alagappan.pdf",
      "accessed": "2026-10-17"
    },
    {
      "id": "hesela",
      "title": "Hesela: Ext4 replay, checksum failure paths and ambiguous tails",
      "url": "https://hesela.com/analyses/ext4-journal-replay-revocation/",
      "accessed": "2026-10-17"
    }
  ],
  "updated": "2026-10-17",
  "provenance": [
    "The paper's protocol model and Hesela's constructed byte example are not present-day field failure measurements."
  ]
}