write() said success. The power went out. The data is gone.

transcript

Your write returns success. Then the machine loses power. You reboot. The data is gone. So what did success mean?

Files go through the kernel's page cache. In RAM. By default, write returns success the moment the data hits that cache. The flush to disk happens later. Crash before that flush? The write never existed.

The fix has a name. fsync. It forces the flush, and returns only when the data is on disk. That's durability.

But here's the catch. A commit touches pages all over the disk. Random writes on a hard disk? About 1 megabyte a second. Sequential? About 100. A hundred times faster.

So databases cheat. Append each change to the end of a log. Sequential. fsync only the log. The data files catch up later. Crash in between? Replay the committed entries from the log.

That's the write-ahead log. PostgreSQL's WAL. InnoDB's redo log. Kafka's append-only log. RocksDB too. Same trick.

A write isn't durable until fsync. And that's why databases append to a log, and fsync that.

Full breakdown in the lecture.