Appearance
30. Journaling
Problem: writing a file isn't atomic — creating one might need 3 separate writes (inode bitmap, data bitmap, actual data). A crash mid-sequence leaves the filesystem inconsistent.
Core idea (write-ahead logging): write your intentions to a log (the journal) first, then apply them.
- Write to journal:
TxB | inode bitmap | data bitmap | data block | TxE - Commit journal (mark transaction committed)
- Checkpoint: apply the actual changes
- Free the journal space
Crash scenarios: crash before TxE → transaction never committed, ignored on reboot, filesystem untouched. Crash after TxE but before checkpoint → replay the journal on reboot, reapplying changes. Crash after checkpoint → nothing to do.
| Mode What's logged Safety Performance | |||
|---|---|---|---|
| Full (data journaling) | Metadata + data | Highest | Slowest |
| Ordered (ext4 default) | Metadata, data written first | Good | Good |
| Writeback | Metadata only | Lowest | Fastest |
Analogy: like writing a to-do list before surgery. If power cuts mid-surgery, the doctor reads the list and knows exactly what was and wasn't done.