Reading — step 1 of 3
Fsync and Durability Modes
Fsync & Durability Guarantees
Writing to a file doesn't mean the data is on disk. The OS maintains a page cache that buffers writes. Without explicit flushing, a power failure can lose "written" data.
The OS Page Cache
When you call write(), the OS copies data to its page cache and returns immediately. The actual disk write happens later, asynchronously:
Application → write() → OS Page Cache → (eventually) → Disk
fast! data in RAM data on disk
This is fast but dangerous: if power fails before the OS flushes, the data is gone.
What fsync Does
fsync(fd) forces the OS to write all cached data for a file to the physical disk and waits for the disk to confirm:
Application → write() → OS Page Cache → fsync() → Disk → confirmed!
After fsync returns successfully, the data is guaranteed to survive a power failure.
Sync Modes
Databases offer configurable durability levels:
| Mode | Behavior | Speed | Safety |
|---|---|---|---|
OFF | No fsync at all | Fastest | Data loss risk |
NORMAL | Fsync WAL on commit | Medium | WAL survives |
FULL | Fsync WAL + database pages | Slowest | Maximum safety |
SQLite exposes this via PRAGMA synchronous:
PRAGMA synchronous = OFF; -- fast, dangerous
PRAGMA synchronous = NORMAL; -- balanced (default in WAL mode)
PRAGMA synchronous = FULL; -- paranoid (default in journal mode)
The Durability Trade-off
Every database makes this trade-off:
Speed ←——————————————————→ Safety
OFF NORMAL FULL FULL+WAL
- OFF: Can lose committed transactions. Acceptable for ephemeral data (caches, analytics).
- NORMAL: Can lose data from the last few seconds. Acceptable for most applications.
- FULL: Committed data survives power failure. Required for financial data.
Write Barriers
Modern hardware adds complexity: disk controllers have their own write cache. Even after fsync, the data might be in the controller's cache. Linux uses write barriers to address this, and databases can disable disk write caching for maximum safety.
How PostgreSQL Handles Fsync
PostgreSQL's fsync setting controls whether it calls fsync at all. The wal_sync_method setting controls which system call to use: fsync, fdatasync, open_sync, or open_datasync. Each has different performance and safety characteristics across operating systems.
In 2018, PostgreSQL discovered a critical bug: if fsync fails, the OS page cache might evict the dirty page, and retrying fsync won't see the data. PostgreSQL now panics (crashes and recovers) on fsync failure rather than silently losing data.
Your Task
Implement PRAGMA sync modes (OFF, NORMAL, FULL) and output the current sync mode with each write operation.
Discussion
Ask a question, share an insight, or help someone who’s stuck.
Sign in to post a comment or reply.
Loading…