Writes That Lie
When a program writes to a file, the operating system usually buffers the data in its own page cache and returns success immediately. The bytes may still be in volatile memory, not on the physical device. A crash at that moment loses them. Fsync is the call that forces buffered writes for a file all the way to stable storage and waits for confirmation.
Why Databases Care
The D in ACID means a committed transaction must survive a crash. To honor this, the engine must fsync its log before acknowledging a commit. Skipping or deferring fsync makes commits faster but risks losing acknowledged transactions.
- A plain write reaches the operating system cache, not the disk.
- An fsync flushes that cache and waits for the device to confirm.
- Some drives also hold a write cache, so the device must honor flush requests for the guarantee to hold.
Pitfalls
- A failed fsync may leave data in an unknown state, so engines treat fsync errors as serious.
- Faster but unsafe settings can disable fsync per commit, weakening durability.
Key idea
A write only reaches the operating system cache; durability requires an fsync that forces the data to the device and waits for confirmation before a commit is acknowledged.