fsync and Crash-Safe Write Ordering

Durability Needs Ordered Persistence

A database page write is not durable until bytes reach non-volatile media. fsync on a file descriptor blocks until prior writes for that file are stored. Crash-safe protocols write the log first, sync it, then write data pages so recovery can replay incomplete updates.

Crash-Safe Sequence

Append WAL record, fsync WAL, modify data page, optionally fsync data. On crash after WAL sync, recovery reapplies committed work.

c
Loading…

fdatasync skips inode metadata when safe
Batching amortizes fsync cost but widens loss window
SSDs buffer in controller RAM; fsync still defines the contract
Order matters more than raw syscall count

Working Through the Exercise

Keep the relevant documentation open while you implement. When your output disagrees with the reference, trace one failing case by hand before changing random lines.

Trace first: walk one failing input step by step
Read the manual: skim the official doc for the mechanism named in this task
Compare baselines: save measurements from the prior step so speedups are honest

Why for this exercise

You will simulate ordered writes and show which steps survive a crash at each point. This exercise asks you to implement the WAL-first sync protocol in the starter simulation.

Write a C program that simulates crash-safe write ordering for a simple database update.

Requirements:

Simulate updating a database with two pages: a data page (page 5) and an index page (page 2) that points to it
Simulate three write strategies: Strategy A (unsafe): write index page, write data page, no fsync. Simulate a crash after index write. Show that the index points to garbage. Strategy B (safe but slow): write data page, fsync, write index page, fsync. Show it is safe but requires 2 fsyncs. Strategy C (WAL): append log record "update page 5, then update page 2", fsync log, write data page, write index page. Simulate crash after log fsync. Show recovery replays the log.
For each strategy, print the sequence of operations and whether data is consistent after crash
Calculate the total fsync count for each strategy
Print a note about group commit: how batching 10 transactions into one fsync reduces fsync count from 10 to 1
Explain why fsync ordering matters more than write ordering (the OS can reorder writes)

Durability Needs Ordered Persistence

Crash-Safe Sequence

Append WAL record, fsync WAL, modify data page, optionally fsync data. On crash after WAL sync, recovery reapplies committed work.

c
Loading…

fdatasync skips inode metadata when safe
Batching amortizes fsync cost but widens loss window
SSDs buffer in controller RAM; fsync still defines the contract
Order matters more than raw syscall count

Working Through the Exercise

Keep the relevant documentation open while you implement. When your output disagrees with the reference, trace one failing case by hand before changing random lines.

Trace first: walk one failing input step by step
Read the manual: skim the official doc for the mechanism named in this task
Compare baselines: save measurements from the prior step so speedups are honest

Why for this exercise

You will simulate ordered writes and show which steps survive a crash at each point. This exercise asks you to implement the WAL-first sync protocol in the starter simulation.

Write a C program that simulates crash-safe write ordering for a simple database update.

Requirements:

Simulate updating a database with two pages: a data page (page 5) and an index page (page 2) that points to it
Simulate three write strategies: Strategy A (unsafe): write index page, write data page, no fsync. Simulate a crash after index write. Show that the index points to garbage. Strategy B (safe but slow): write data page, fsync, write index page, fsync. Show it is safe but requires 2 fsyncs. Strategy C (WAL): append log record "update page 5, then update page 2", fsync log, write data page, write index page. Simulate crash after log fsync. Show recovery replays the log.
For each strategy, print the sequence of operations and whether data is consistent after crash
Calculate the total fsync count for each strategy
Print a note about group commit: how batching 10 transactions into one fsync reduces fsync count from 10 to 1
Explain why fsync ordering matters more than write ordering (the OS can reorder writes)

Topic Overview

Durability Needs Ordered Persistence

Crash-Safe Sequence

Working Through the Exercise

Why for this exercise

Implementation Task

Progressive Hints

Resources

Open Source

fsync and Crash-Safe Write Ordering

Topic Overview

Durability Needs Ordered Persistence

Crash-Safe Sequence

Working Through the Exercise

Why for this exercise

Implementation Task

Progressive Hints

Resources

Open Source