Battery-backed memory and NVRAM
What changes when the durability point moves closer to the CPU, and what does a failing battery look like?
Everything in Logs and undo and Group commit and fsync kept the durability point fixed at the media and tried to shorten the path to it, by batching more work per flush. This section does something different: it moves the durability point. It does not spread the fixed cost. It removes it.
Three generations of the same idea, each moving the point closer to the CPU:
- Battery- or flash-backed write cache on a RAID controller. DRAM plus a supercapacitor (or battery). A write that reaches the cache is declared durable, because the energy needed to finish it is stored locally.
fsyncfalls from one disk rotation (~8 ms) to a PCIe round trip (~100 µs), about 100×. The commit bottleneck changes from mechanical to electrical. - Power-loss protection (PLP) inside an SSD. The same trick inside the drive. With capacitors, the drive can answer FLUSH almost instantly, because its volatile cache is effectively non-volatile. This produces the most important invisible fact in database hardware sizing: the identical
fsync()call costs about 20 µs on an enterprise NVMe with PLP, and 1–2 ms on a consumer NVMe without it. Same software, same API, 50–100× apart. The difference appears on no spec sheet that lists only IOPS. Drives without PLP either flush slowly or lie, and the ones that lie are indistinguishable from the fast ones until you pull the power. - Persistent memory (NVDIMM-N, Optane DCPMM). Memory you can address by byte, with sub-microsecond access, whose durability point is inside the memory hierarchy. The question changes from "when do I flush?" to "which cache lines are persistent, and in what order?" The log record no longer has to be a block. You can persist a pointer swap.
The general principle
Watch it with one substitution:
| Cost of one durable flush | Natural group-commit batch | Doublewrite's 2× | Log latch and syscall |
|---|---|---|---|
| 8 ms (hard disk) | ~4,000 records | invisible behind seek time | nobody looks at them |
| 20 µs (NVMe with PLP) | ~300 records | now a headline cost; worth buying atomic-write hardware to remove | dominate the commit path |
The fixed cost has migrated twice in one section: media → syscall and latch → protocol.
What it assumes but cannot verify: that the capacitor is charged and the firmware will finish the job. A degraded battery makes controllers fall back silently to write-through (each write goes to disk before it is acknowledged). The symptom is a 50× throughput collapse in a system that is still perfectly correct. It is the hardest class of incident to diagnose, because nothing is broken and every check passes. (This is Nadia's second incident.)