On an ext4 filesystem, what does the journal actually protect after an unclean shutdown, and how do the data=ordered, data=writeback and data=journal mount options differ?

## Why a journal exists at all A single logical operation — appending to a file — touches several independent structures on disk: the block allocation bitmap, the inode's size and extent tree, possibly a directory entry. If power is lost between those writes, the filesystem is internally inconsistent: blocks marked used that no file claims, or worse, a file whose extents point at blocks the allocator also handed to someone else. Historically the fix was a full check at boot (`fsck`), whose cost scales with the size of the filesystem, and which on a multi-terabyte volume means a very long outage. A journal turns that into a bounded operation. ext4 writes a description of the change to a dedicated on-disk area first, commits it, and only then applies the change in place. After a crash the kernel finds the journal non-empty at mount time and replays it, and the filesystem is consistent again. This is why an ext4 root filesystem comes back in seconds after an unclean reboot rather than sitting at a progress bar. ## Metadata is journaled; data is a separate question The crucial distinction is that, by default, only metadata goes through the journal. A consistent filesystem is not the same as a correct file. Consider appending 4 KiB to a file: the metadata change says "this inode now owns block N and is 4096 bytes longer". If that metadata commit lands but the 4 KiB of data never reaches block N, the filesystem is perfectly consistent — and your file now contains whatever bytes block N held previously, possibly from a deleted file belonging to someone else. That is both a correctness problem and an information-disclosure problem. The `data=` mount option is the knob that decides how much the filesystem does about this. ## The three modes **`data=ordered` (the default).** Metadata is journaled, and ext4 additionally guarantees ordering: a transaction's data blocks are pushed to the device *before* the metadata transaction that references them is committed. You never see metadata pointing at blocks whose contents were never written, so the stale-block exposure above cannot happen. The cost is a write barrier between data and metadata, which serialises some workloads. **`data=writeback`.** Metadata is journaled, but there is no ordering constraint against data. Metadata may be committed first, and if the machine dies in the window before the data lands, the file legitimately contains stale block contents. It is the fastest of the three and is defensible for filesystems where you genuinely do not care about the contents of files being written at the moment of a crash — a scratch or cache volume — and indefensible for a general-purpose or multi-tenant filesystem. **`data=journal`.** File data is written into the journal as well as to its final location. Nothing can be torn or stale, at the price of writing every byte twice; throughput on write-heavy workloads falls sharply. It also disables ext4's delayed allocation. It is used where correctness dominates and the write volume is modest. The mode is chosen at mount time. You make it persistent in the fstab entry or by setting the filesystem's default with `tune2fs`, and you cannot switch modes on a mounted filesystem: ``` tune2fs -l /dev/sdb1 | grep -E 'Filesystem features|Default mount options' tune2fs -o journal_data_writeback /dev/sdb1 ``` ## Delayed allocation, and the famous zero-length files Modern ext4 uses extents (contiguous block ranges recorded as start-plus-length) instead of ext3's indirect block maps, and it uses *delayed allocation*: when you write, the data sits in the page cache and no blocks are chosen until writeback, which lets the allocator pick better, more contiguous placement. That is a real performance win, and it lengthened the window in which a crash loses recent writes. When ext4 became widespread, users reported files that were zero length after a crash — applications had used the write-a-temporary-file-then-`rename()`-over-the-original idiom without calling `fsync()` before the rename, so the rename's metadata was durable while the data was still only in the page cache. ext4 gained heuristics that force allocation and writeback for these truncate-and-replace and rename-replace patterns, but the underlying lesson stands: the filesystem's ordering guarantees are about its own structures, and durability of your bytes is what `fsync()` (or `fdatasync()`) is for. A database that omits it is not saved by any `data=` mode. ## What to say in the interview Separate the two guarantees explicitly. The journal buys fast, bounded recovery of the filesystem's structure. `data=ordered` additionally buys the promise that a file never exposes blocks whose contents were not written. Neither buys durability of a specific `write()` — only `fsync()` does, and only if the device is not lying about its own cache flushes.