The Disk Cache Deception
Hard drives and SSDs are optimizers by nature. When the OS tells a drive "write this data now," the drive often acknowledges immediately — but stores the data in its own internal DRAM write cache and physically commits it to the storage medium later, when it is convenient for the drive's internal scheduler.
This is normally fine for performance. But it breaks journaling in a subtle and dangerous way.
Consider this scenario:
1. The kernel writes the journal commit record. The drive says "done" — but it is sitting in the drive's DRAM cache.
2. The kernel writes the actual data block to disk. The drive physically commits this one immediately (perhaps because it was in a more convenient location on the platter).
3. Power fails.
4. On reboot: the data block is on disk, but the journal commit record vanished with the drive's DRAM. The journal looks like an incomplete transaction and is discarded. The data block is now orphaned — written without any metadata update. The filesystem is corrupt.
The journal protected nothing because the drive lied about write ordering.
Write Barriers
A write barrier is a kernel command to the storage device that means: "Flush your internal write cache to persistent storage right now. Do not acknowledge completion until the data is physically safe. Do not reorder writes across this boundary."
The kernel issues a barrier after writing the journal commit record. This guarantees the journal is truly on disk before the checkpoint phase begins. Barriers are enabled by default on ext4 (the nobarrier mount option turns them off) — a deliberate, explicit trade-off rather than something you'd stumble into.
When is nobarrier safe?
- Battery-backed RAID controllers (BBU RAID): The controller has a battery that preserves its DRAM cache through a power failure. The hardware guarantees write ordering, so the kernel barrier is redundant.
- Volatile scratch/cache workloads where data loss is explicitly acceptable.
- Virtual machines where the hypervisor provides write ordering guarantees.
Key Point: The performance cost of barriers is real — on spinning disks, a barrier forces a full rotational wait (potentially 4–8ms per barrier). On SSDs, the cost is lower but nonzero. This is why battery-backed RAID controllers are standard in production database servers: they let you disable barriers without sacrificing safety, recovering significant write throughput.