Skip to content
Fsync & Durability Guarantees
step 1/3

Reading — step 1 of 3

Fsync and Durability Modes

~2 min readWrite-Ahead Log

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:

ModeBehaviorSpeedSafety
OFFNo fsync at allFastestData loss risk
NORMALFsync WAL on commitMediumWAL survives
FULLFsync WAL + database pagesSlowestMaximum 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…