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

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.