Does an SSD Benchmark Measure the OS Cache or the Drive?
- A buffered file test can be influenced by the host page cache; a fast result alone does not prove where the I/O was served.
- Change one variable at a time and retain the workload, cache state, device counters and application timing for each run.
- Direct I/O can reduce host page-cache effects where supported, but it does not bypass SSD-side caching or establish power-loss durability.
A fast file benchmark does not, by itself, show that the SSD delivered every reported byte at that speed. The host may serve repeated reads from memory or acknowledge buffered writes before they reach the device. Other runs through the same buffered interface may still reach the SSD. To tell which case matters for your equipment, record the test conditions and compare controlled runs rather than interpreting one headline throughput number.
This guide is for engineers qualifying a storage candidate on a real host. It addresses host operating-system caching. The separate SLC-cache and sustained-write explanation covers an SSD-side effect that can remain even when host caching is reduced.
Know which cache the test can see
A normal file read may be satisfied by the operating system's page or file cache after an earlier read. Buffered writes may initially reside in host memory and be written back later. Microsoft's Cache Manager documentation describes the Windows file-cache behavior; the exact path depends on the application, operating system, filesystem and test tool.
An SSD can also buffer or rearrange writes internally. Some drives have controller DRAM; others do not. An SLC write cache uses NAND in a faster operating mode. Avoid calling all of these “the SSD cache”: host memory, controller memory and NAND write behavior answer different questions.
Use a controlled comparison
Start with a dedicated, disposable test file or drive and a backed-up system. Writing to a raw block device can destroy its partitions and data. Capture the exact drive model and firmware, host, OS, filesystem, interface, free capacity, temperature location and power setting. Keep these constant between candidates and note any change.
| Record for each run | Why it matters |
|---|---|
| Read or write; sequential or random; block size, concurrency and runtime | These define the workload. A different queue depth can change the result more than the cache setting. |
| File size and working set; host RAM size | A repeatedly read working set that fits in available memory is especially susceptible to cache hits. No single file-to-RAM ratio guarantees isolation. |
| Buffered or direct I/O; test engine and filesystem | Direct I/O can reduce page-cache use where the platform and engine support it. Confirm actual support and alignment requirements. |
| First and repeated runs; prior cache state | A warm read can behave differently from a first read. Document any attempted invalidation and whether it succeeded. |
| Device-level I/O counters and application timing | If a file test reports bytes but device counters barely move, investigate cache hits. Counters alone may not explain every layer. |
| Throughput, latency distribution and errors | Keep both averages and relevant tail latency, plus the complete result rather than one screenshot. |
First repeat the same buffered workload while changing only the prior cache state. For a read test, compare an initial run with repeated runs on the same file; a large improvement with little corresponding device read activity supports a host-cache explanation. A cold run is difficult to guarantee without platform-specific controls, so record what was actually done. Next, if supported, compare buffered and direct I/O with the same read/write pattern, working set and duration. A difference is evidence to investigate, not proof that one result is the device's universal speed.
fio documents options such as direct, invalidate, workload size, verification and latency output. direct=1 requests non-buffered I/O through the selected engine; support and behavior vary by platform and target. invalidate=1 requests cache invalidation before a run, but should not be reported as a guaranteed purge on every system. Keep the actual job file and tool version with the results. If an option is unsupported or falls back, note that instead of labeling the run “uncached.”
Separate speed, endurance and persistence questions
Direct I/O is not a request to bypass the SSD controller, its write buffers or NAND SLC behavior. To see a sustained-write transition, run long enough and across enough data for the particular drive and fill state, then report the time series. To assess endurance, use the actual host-write workload and the exact candidate specification. Neither question is answered by a short cache comparison.
Likewise, direct I/O does not prove that an acknowledged write will survive sudden power loss. Flush or synchronization behavior, SSD power-loss protection and application recovery require a separate qualification plan on the target stack. Do not infer durability from a benchmark mode or throughput figure.
In summary, a normal SSD benchmark measures the whole storage path, including the application, OS, filesystem, host interface and drive, rather than NAND alone. To estimate the drive's contribution, control those host variables, reduce page-cache effects where supported and compare device-level activity. Direct I/O cannot remove every host-stack effect or bypass the SSD controller; measuring NAND behavior itself requires drive-level vendor instrumentation or documentation.
For an RFQ, provide the test table, raw results and the application deadline the storage must meet. State which behavior was measured on your host and which remains unknown. Attach the recorded conditions to an RFQ using this template or a quote request; the final part still needs qualification in the actual device.
We publish measured usable capacity and define trial-batch verification against the quoted product and agreed test scope.