In this chapter
We'll look at what protects real directory and inode updates from a crash mid-write: journaling, the same write-ahead-log discipline already met at the database layer, applied here to keep a file system's own structures consistent even after an unexpected power loss.
The Problem in Real Life
Mike asks a real, sharp question. "All these directory tables and inodes — what happens if the server loses power in the middle of updating one? Does the whole file system just... break?"
Sarah smiles. "It used to, on older file systems, more often than you'd want. Modern ones have a real answer for exactly this."
What actually stops a mid-write power loss from corrupting everything?
Mike
A Change Applied Directly vs. A Change Written Down First
A multi-step update can be caught half-done
Deleting a file involves several separate real updates — a crash between them can leave genuinely contradictory state.
Write the intent down first
A journal records exactly what's about to change before it's applied — recovery replays the log instead of guessing at the whole disk.
Journaling & Crash Recovery
Updating a file often means changing more than one real structure at once — a directory entry, an inode's link count, a block pointer. If power cuts out after only some of those updates land, the file system is left in a real, inconsistent state. Journaling is the mechanism most modern file systems use to make that recoverable.
- The real risk of a multi-step update. Deleting a file, for instance, genuinely involves several separate updates: removing the directory entry, decrementing the inode's link count, and — once that count hits zero — marking its data blocks free again. If the machine loses power after only the first of those lands, the file system can end up with real, contradictory state: an inode with no directory entry pointing at it, or blocks marked "in use" that nothing valid actually references anymore.
- A journal — write the intent down first. A journaling file system keeps a real, dedicated log area (the journal) and, before actually modifying the real directory tables and inodes, first writes down exactly what it's about to do. Only once that intended change is safely recorded does it go on to apply the real change to the actual file system structures.
- Recovery becomes replaying a log, not guessing. After a real crash, instead of scanning the entire disk trying to guess what state it was left in (a slow, real process older file systems relied on), a journaling file system just reads its own journal: any entry marked complete but not yet fully applied gets replayed; any entry that was still being written when power was lost gets safely discarded. This turns an unpredictable, whole-disk repair into a fast, bounded, mechanical replay.
- The same real idea already met at the database layer, one layer lower. This is genuinely the same write-ahead-log discipline covered for databases — record the intended change durably before applying it, so a crash mid-operation is always recoverable by replaying what was actually, safely recorded. A file system's journal exists for exactly the same reason a database's write-ahead log does: it's cheaper and more reliable to write down intent first than to reconstruct truth after the fact.
GreenMart's own servers rely on this mechanism every single time they lose power unexpectedly, without anyone at GreenMart ever having to think about it — real file system corruption from a mid-write crash is, on a properly journaled file system, a genuinely rare event rather than a routine one.
Key Takeaway
Journaling protects a file system the same way a write-ahead log protects a database — by writing down intent durably before acting on it, turning an unpredictable crash into a fast, bounded, mechanical replay instead of a real guessing game.
Why This Matters
Every real server outage GreenMart experiences — a crashed process, a power blip in a data center — puts this mechanism to work automatically. Understanding it explains why a modern server usually boots back up cleanly after an unexpected crash, instead of requiring a long, manual disk repair.
GreenMart now understands journaling as the same write-ahead discipline seen at the database layer, applied here to protect real directory and inode updates from a mid-write crash. The next chapter turns to a different real risk entirely: who's actually allowed to read or change a file in the first place.