{
  "slug": "crash-consistency",
  "term": "Crash consistency",
  "aliases": [
    "crash consistency"
  ],
  "definition": "Crash consistency is the property that persistent state remains within an application's allowed recovery states after an unexpected interruption.",
  "note": "It is distinct from preserving every acknowledged update: an older, internally consistent state may still violate durability. Pillai et al. distinguish persistence ordering and atomicity, while SQLite documents a concrete rollback-journal protocol. Filesystem metadata consistency alone does not establish that an application's multi-file transaction committed.",
  "status": "shipping",
  "advantages": [],
  "limitations": [],
  "related": [
    "fsync",
    "writeback-error",
    "copy-on-write"
  ],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "citations": [
    {
      "id": "pillai-2014",
      "title": "Pillai et al. (OSDI 2014): All File Systems Are Not Created Equal",
      "url": "https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf",
      "accessed": "2026-10-10"
    },
    {
      "id": "sqlite-atomic",
      "title": "SQLite: Atomic Commit",
      "url": "https://www.sqlite.org/atomiccommit.html",
      "accessed": "2026-10-10"
    },
    {
      "id": "hesela-fsync",
      "title": "Hesela: Why retrying a failed fsync does not prove durability",
      "url": "https://hesela.com/analyses/fsync-failure-retry-durability/",
      "accessed": "2026-10-10"
    }
  ],
  "updated": "2026-10-10"
}