the write-ahead log (WAL)
/ WAL = wawl /
Suppose you must update three different spots and the update is only correct if all three change together, yet a crash can stop you between any two. The safe move is to write down the full plan in one place first, securely, before touching any of the three. Then if you crash partway, you can read the plan back and either finish it or know it never started. That write-the-plan-down-before-acting rule is the write-ahead log, and it is the engine underneath both filesystem journaling and database durability.
The defining rule of a WAL is in its name: the log entry describing a change must reach stable storage BEFORE the change is applied to the main data in place. Concretely, you append a record (often the new values, a redo log) to the log, force it to disk, and only then update the actual data structures. The log is written sequentially - appended to the end - which is fast even on spinning disks because it avoids random seeks. On restart after a crash, recovery scans the log forward: completed transactions (those with a commit marker) are reapplied (redone) to bring the main data up to date, and unfinished ones are ignored or undone. The same idea appears as ARIES in databases, as the journal in ext4, and as PostgreSQL's WAL files.
Why it matters: the WAL is how systems get atomic, durable, all-or-nothing updates on hardware that can only write one block at a time and can lose power at any instant. The honest catch is that the durability promise rests entirely on that one forced write to the log actually being on stable media - if the log write is buffered in a volatile disk cache that is lost on power failure, the guarantee evaporates. That is why correct WAL implementations issue a real cache-flush or use FUA (force-unit-access) writes, and why a lying drive that ignores flushes can silently break the whole scheme.
rule: log-record-on-disk BEFORE in-place-update append LOG: "set block 941 = X"; fsync/FUA the log <- durable plan then apply: write X to block 941 in the main area recovery scans log: redo committed records, ignore the rest
The log record is forced to disk before the in-place change; recovery redoes committed records.
The WAL's durability guarantee is only as strong as the flush behind it. If the forced log write lands in a volatile disk cache that a power cut erases - or in a drive that ignores cache-flush commands - the all-or-nothing promise is silently void. A correct WAL flushes or uses FUA, and trusts only what survives power loss.