---
title: "Crash Consistency and the Journal"
description: "A crash during a multi-block update can leave only part persistent. In the physical redo metadata-journal model taught here, durable redo records and a durable commit precede home metadata writes. Rec"
canonical: https://lightmysky.com/learn/computing/crash-consistency-and-the-journal-mt_I9DT0TUmiu
source: https://lightmysky.com/learn/computing/crash-consistency-and-the-journal-mt_I9DT0TUmiu.md
retrieved: 2026-11-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Crash Consistency and the Journal

A crash during a multi-block update can leave only part persistent. In the physical redo metadata-journal model taught here, durable redo records and a durable commit precede home metadata writes. Recovery replays valid committed transactions and ignores incomplete ones. Other journal designs can differ.

Subject: Computing · Area: Computer Systems · Ages 20 to 22
Page: https://lightmysky.com/learn/computing/crash-consistency-and-the-journal-mt_I9DT0TUmiu

## Ready when they can

- Describe a crash state that violates a same-file-system rename's expected before-or-after result
- Order durable redo records, durable commit and home metadata writes in the taught model
- Explain committed and incomplete transaction recovery, repeat-safe replay and metadata-only journalling limits

## Lesson: Journal records before home blocks

A file-system operation can update several storage blocks. A crash may leave only some changes persistent, violating the expected before-or-after result. Not every crash causes inconsistency. Here we use a physical redo metadata journal: it logs updated metadata block images for later writing to their normal, or home, locations.

**Example.** Consider a same-file-system rename between directories, with an unused destination name. The file record stays the same; directory entries change. Without crash protection, removing the old entry before the new one is durable can leave neither name after a crash. Two names can be valid hard links, but are not this rename's intended final result.

First write the transaction's redo records and make them durable. Then write its commit record and make that durable. Only then may this transaction's metadata updates reach home blocks. Issuing writes in order is insufficient: storage must preserve the required earlier stage before the next is allowed.

Recovery replays complete, valid transactions with durable commits, because their home writes may be unfinished. It ignores incomplete transactions without valid commits. This is safe in our model because uncommitted metadata could not reach home blocks. A commit identifies a recoverable transaction; it does not prove all home writes finished.

*(drawing: These recovery rules apply to the stated redo model.)*

Physical redo writes recorded block images to fixed home locations. Repeating the same image write, with no intervening update, leaves the same contents. Recovery does not run a file-copy command again. Once home updates are durable, checkpointing can permit journal space to be reclaimed. Reclaiming it earlier could remove the only durable recovery copy.

A metadata-only journal protects file-system structure, not necessarily the latest user-data bytes. Data journalling and data-write ordering are separate choices. Recovering a consistent directory entry does not alone prove the newest document contents were saved. A journal on the same device is also not a separate backup.

**Recap.** In this redo model, durable records and commit precede home writes. Replay valid committed records; ignore incomplete transactions. Metadata recovery is not a backup.

*Lesson, worked questions and flashcards about a physical redo metadata-journal model were written for this dataset.*

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [File Systems: Names, Blocks and Metadata](https://lightmysky.com/learn/computing/file-systems-names-blocks-and-metadata-mt_jN4u3idvF3)

## Opens up

- [Crash Recovery and Write-Ahead Logging](https://lightmysky.com/learn/computing/crash-recovery-and-write-ahead-logging-mt_JFPafSWOWF)
