Archivestorage
The WAL Is Only as Durable as Your fsync
A write-ahead log makes crash recovery possible — if the record actually reaches stable storage before you acknowledge.
- Published
- Reading time
- 1 min read
A write-ahead log records changes before they are applied to data pages. On crash, recovery replays committed records and discards incomplete ones.
The commit protocol
append(record) → fsync(log) → acknowledge client → apply to pages later
The acknowledgment must come after the fsync. If you acknowledge before the log is durable, a power loss loses an acknowledged write — the exact failure the WAL was meant to prevent.
Group commit
Fsync is expensive, so databases batch: many transactions share one fsync, and all are acknowledged after it completes. This is why throughput improves with concurrency up to a point.
Details that bite
fsyncon a directory is needed when creating or renaming files.- Some filesystems and virtualized disks lie about flushing (see fsync lies).
- Replication does not replace local durability for the write you acknowledged.
Takeaway: the durability point is the fsync, not the write call. Place your acknowledgment exactly there.