# Journaling Filesystems: How ext4 Survives a Crash

> Pull the power mid-write and a naive filesystem corrupts. A journal is the write-ahead log that lets ext4 come back consistent — by promising to do work before actually doing it.

URL: https://harshith.in/blog/journaling-filesystems/
Author: Harshith Sunku (Staff Engineer) — https://harshith.in/about/
Tags: filesystems, systems

A single file write isn't one operation to the disk — it's several: update the
data blocks, the inode, the free-space bitmap, maybe a directory entry. Lose
power between them and the filesystem is left in a contradictory state. A journal
is how ext4 turns "several steps" back into something that's all-or-nothing.

## Why a Crash Corrupts

Appending to a file touches multiple structures that must stay consistent:

```text
   1. write the new data blocks
   2. mark those blocks used in the bitmap
   3. update the inode's size and block pointers
```

Crash after step 2 but before 3, and the bitmap says "used" while no inode points
there — leaked space. Crash between 1 and 2, and the inode may point at blocks the
bitmap thinks are free, to be handed to another file later — **corruption**. The
old fix was `fsck` scanning the entire disk on boot, which takes minutes to hours
on a large volume.

## Write-Ahead: Say It Before You Do It

A journal is a reserved on-disk area where the filesystem first records *what it
is about to do*, then does it. The sequence:

```text
   1. write the intended changes to the journal    ("transaction")
   2. mark the transaction committed                (a commit record)
   3. apply the changes to their real locations     ("checkpoint")
   4. mark the journal entry free
```

The commit record in step 2 is the atomic switch. After a crash, recovery just
replays the journal:

```text
   transaction committed?  ──yes──▶ replay it (redo the changes)
                           ──no───▶ discard it (it never happened)
```

Either the operation fully happened or it fully didn't. Recovery reads a small
journal, not the whole disk — seconds, not hours.

## The Three Modes of ext4

Journaling everything is safe but doubles writes — data goes to the journal *and*
its final home. ext4 lets you choose what's protected:

```text
   journal    metadata + data both journaled   safest, slowest
   ordered    metadata journaled; data written
              before the metadata commit         default, good balance
   writeback  metadata journaled; data unordered fastest, can show stale
                                                  data after a crash
```

**Ordered** mode (the default) is the clever compromise: it doesn't journal file
data, but it forces data blocks to disk *before* committing the metadata that
points to them. So metadata never references garbage — you won't see another
file's old contents — without paying to journal data twice.

## The Limit

A journal guarantees the *filesystem* is consistent, not that your application's
data is. A committed transaction can still represent a half-written file from the
app's point of view. That's what `fsync()` is for — and why databases call it
religiously before reporting a write durable.

## Takeaways

- Filesystem operations touch several structures; a crash between them corrupts
  the volume.
- A journal is a write-ahead log: record the intent, commit atomically, then
  apply — so recovery replays or discards whole transactions.
- ext4's ordered mode protects metadata and orders data before the commit,
  balancing safety and speed without journaling data twice.
- Journaling protects filesystem consistency, not application durability — that's
  still on `fsync()`.