TL;DR
Benchmarks on several machines show consumer SSDs can deliver fast raw writes but exhibit much higher fsync latency when they lack power-loss protection (PLP). InnoDB's O_DIRECT mode triggers periodic fsyncs per batch of writes; switching to O_DIRECT_NO_FSYNC greatly reduces fsync frequency and can mitigate the impact of slow syncs.
What happened
The author ran fio-based microbenchmarks and an InnoDB insert benchmark across multiple machines to measure fsync and fdatasync behavior for files opened with O_DIRECT. Test configurations included 16 KB and 2 MB writes, with variants that did or did not call fsync/fdatasync per write; results are reported primarily for single-job runs. Machines included consumer SSDs (Crucial T500, Samsung 990 Pro), cloud-attached NVMe and Hyperdisk Balanced storage, and enterprise/datacenter SSDs (Intel D7-P5520/Solidigm, Samsung PM-9a3). The tests found a recurring pattern: consumer drives without PLP showed much higher sync latency (milliseconds) even while raw write throughput remained high, while enterprise drives and some cloud/local NVMe setups showed sync latencies in the low microseconds to tens of microseconds. The author concluded the Crucial T500 offered lower fsync latency for their mini-PCs compared with the Samsung 990 Pro and plans to switch.
Why it matters
- High fsync latency on drives without PLP can sharply reduce application throughput when software issues frequent fsync calls (InnoDB O_DIRECT behavior is one example).
- Choosing an SSD with power-loss protection, or changing database flush settings, can materially affect durability vs performance trade-offs.
- fdatasync often measured lower latency than fsync in these tests; the difference varies by device and storage stack.
- Benchmark results depend on hardware and filesystem configuration; testing on target hardware is important before tuning or deploying.
Key facts
- InnoDB with innodb_flush_method=O_DIRECT issues fsync calls per batch of writes rather than necessarily after each page write.
- Changing innodb_flush_method to O_DIRECT_NO_FSYNC reduces fsync frequency; observed ratios (Innodb_data_fsyncs / Innodb_data_writes): O_DIRECT: 0.01046 (5.7.44) and 0.00729 (8.0.44); O_DIRECT_NO_FSYNC: 0.00172 (5.7.44) and 0.00053 (8.0.44).
- Tested servers included: dell (Crucial T500 consumer SSD, fsync ~1 ms), ser7 (Samsung 990 Pro consumer SSD, fsync several ms), hetz (Intel D7-P5520 datacenter SSD, PLP claimed), socket2 (Samsung PM-9a3 enterprise SSD, PLP claimed), and gcp (local NVMe and Hyperdisk Balanced).
- Sync latency after 16 KB writes (fsync / fdatasync in microseconds): dell 891.1 / 447.4; hetz 12.4 / 9.8; ser7 2974.2 / 2783.2; socket2 1.6 / 0.7; gcp local 56.2 / 28.1; gcp Hyperdisk 738.1 / 46.8 (ext-4 results shown).
- Sync latency after 2 MB writes (fsync / fdatasync in microseconds): dell 980.1 / 449.7; hetz 58.2 / 10.8; ser7 5396.8 / 3508.2; socket2 139.1 / 2.2; gcp local 1020.4 / 832.4; gcp Hyperdisk 821.2 / 63.6.
- Throughput impact on the Dell system (16 KB writes, single job): no-sync ~43,400 writes/s (~647 MB/s); with fsync per write ~1,083 writes/s (~16.1 MB/s); with fdatasync per write ~2,100 writes/s (~31.3 MB/s).
- The author observed that enterprise SSDs and some local NVMe setups returned much lower sync latencies compared with consumer SSDs that lack PLP.
- fdatasync latency was frequently lower than fsync latency in these measurements, with the magnitude of the difference varying by device and storage configuration.
What to watch next
- Measure fsync and fdatasync latency on the exact hardware and filesystem configuration you plan to use before relying on consumer SSDs.
- If your workload issues frequent fsyncs (or uses InnoDB O_DIRECT), test both O_DIRECT and O_DIRECT_NO_FSYNC settings to understand exposure to slow syncs.
- Consider SSDs with explicit power-loss protection (PLP) if durability under sudden power loss and low sync latency are important for your workload.
Quick glossary
- fsync: A system call that flushes all modified data and metadata for a file to durable storage to ensure data is persisted.
- fdatasync: A system call that flushes a file's data (but may exclude some metadata) to durable storage; often faster than fsync when metadata updates are not required.
- Power-loss protection (PLP): Hardware features in some SSDs (such as capacitors) designed to provide enough power to flush volatile write caches to NAND in the event of sudden power loss.
- O_DIRECT: A file-open flag that requests direct I/O to bypass the OS page cache, often used by databases to avoid double buffering.
- InnoDB: A storage engine for MySQL and MariaDB that manages data flushing, crash recovery and other durability mechanisms for transactional workloads.
Reader FAQ
Does InnoDB call fsync after every single page write when using O_DIRECT?
The source argues that InnoDB does not call fsync after each individual write; it may call fsync once per batch of writes and the doublewrite buffer is fsynced.
Are consumer SSDs always unsafe without PLP?
not confirmed in the source
Is fdatasync generally faster than fsync?
In these tests fdatasync often had lower latency than fsync, but the difference varied by device and storage configuration.
Should I buy enterprise SSDs to avoid slow fsync?
The author suggests enterprise SSDs reduce sync latency and risk, but they are more expensive and larger; testing your workload on target hardware is recommended.
Small Datum Wednesday, January 7, 2026 SSDs, power loss protection and fsync latency This has results to measure the impact of calling fsync (or fdatasync) per-write for files opened with…
Sources
- SSDs, power loss protection and fsync latency
- Why Your SSD (Probably) Sucks and What Your Database …
- A Closer Look At SSD Power Loss Protection
- On the impact of fsync in the storage node upload code …
Related posts
- Show HN: I visualized the entire Citi Bike history in-browser
- LaTeX Coffee Stains (2021 PDF): Notes on the CoffeeStains Package
- Butter adds automatic template induction to improve dynamic LLM response caching