Understand fsync, I/O Barriers, and Disk Write Ordering

Topic Overview

Durability Ordering

fsync and fdatasync push buffered writes to stable storage. I/O barriers constrain reordering so journal records hit disk before metadata they protect. Databases depend on these ordering guarantees.

Write Path Guarantees

Stack layers:

• Page cache: lazy writeback
• fsync: flush file blocks and metadata needed for durability
• Barrier flag: block layer serializes dependent writes

For example, SQLite relies on fsync after journal write before committing the main db page; skipping it risks corruption on power loss.

Why This Matters in Production

SQLite and Postgres both rely on fsync() plus write ordering to guarantee that a committed transaction survives a power loss, and both batch writes into a single fsync (group commit) because one fsync on spinning disk can cost 5-20 milliseconds. Skipping the barrier between two dependent writes is exactly how the classic 'transfer $100, crash mid-way, money disappears' bug happens in real financial software.

Debugging Checklist

Before you call the implementation done, walk failure modes on purpose. Test empty structures, single-element edge cases, maximum concurrency, and errno paths that must not crash the program. OS code usually fails in production when happy-path tests pass but invariants break under contention or memory pressure.

Implementation Notes

Keep structures small and name fields after kernel counterparts when possible. That lets you read man pages and kernel source side by side while you work. Print observable events during development; remove noisy logs once tests pass reliably.

For This Exercise

You will trace a write with and without fsync using strace or your block cache, and explain which crash windows remain. The task asks you to pair journal commits with barrier semantics from the journaling task.

Your Task

Model what survives a power failure. Writes land in the page cache, and only fsync makes a file's data durable. Creating or renaming a file changes its directory, and that change is only durable after the directory itself is fsynced. Simulate the page cache, the durable disk and a crash, and show why the classic safe-save sequence is write temp → fsync temp → rename → fsync dir. Also count fsync latency, to show why databases batch commits (group commit).

State

• cache view: what programs see: file contents and the directory's name → file mapping.
• disk: the durable contents of each file (by file identity) and the durable directory mapping.

Files have an identity (#1, #2, … in creation order) separate from their names, like inodes.

Commands

Every fsync/fsyncdir costs LAT microseconds, set by a first line latency LAT. C is the running total. Files and entries print in name order. A file that is named durably but whose data was never fsynced survives a crash empty, and an unnamed file is lost. view: empty / after crash: empty when there are no names.

Errors: write/fsync/rename of a missing name → COMMAND NAME: ENOENT.

The final line is total: F fsyncs, T us.

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

The rename was never made durable, so the old version survives, and survives intact. Hidden tests show the other orders: rename without fsyncing the new file's data (the name points at an empty file after the crash), and the fully safe sequence.

Requirements

1. Keep the cache view and the disk state as separate structures; crash replaces the view with the disk state.
2. fsync copies a file's data only; fsyncdir copies the name mapping only.

Hidden tests cover the complete safe-save sequence, a rename whose data was never fsynced, a new file that was fsynced but whose directory entry wasn't, many small writes committed with one fsync compared with one fsync per write, and ENOENT errors.