CPU, GPU AND RAM

fio buffered and direct reads measure different paths

In this article
THE QUICK TAKE

Buffered and direct reads measure declared paths; cache mode and preparation belong in every published result.

Name the path before comparing results

A buffered read and a direct read can answer different questions even when they use the same file. One may exercise a warm operating-system cache; the other requests a non-buffered path where supported. Comparing their bandwidth without declaring the cache mode can make host RAM look like a faster SSD or make a valid application path look like a misleading result.

The fio reference defines buffered and direct I/O controls and notes platform limitations. A direct setting does not remove every layer of the storage stack or turn a filesystem test into a measurement of raw flash. State exactly which path was requested and whether the environment supported it.

Use an existing bounded test file

Choose a known file whose contents and size are recorded, with permission for the test workload. Explicitly select reading and use fio’s read-only safety option. Keep writes, trims and automatic creation out of a read investigation. Do not substitute a whole raw device merely because an example on another system used one.

Record the installed fio version, engine, file range, block size, queue settings and duration. Preserve the complete job definition with the result. A label such as SSD benchmark is not enough to reconstruct whether the test read a small cached range repeatedly or covered a much larger working set.

Document cache preparation

The Linux virtual-memory documentation explains cache reclamation and the costs of deliberately dropping caches. Avoid making system-wide cache eviction a routine step on an occupied server. It changes other workloads and can make the environment less representative of the application being examined.

Instead, define the isolated test conditions and state what is known about cache history. A repeated buffered pass can intentionally measure a warm path. A direct read can provide a different baseline where supported. Neither should be renamed cold storage without evidence about the remaining filesystem, device and platform caching layers.

Interpret the difference carefully

Suppose an illustrative warm buffered run completes much faster than the direct run. That result can be compatible with cache service and does not demonstrate that the SSD’s physical throughput changed. If a direct job fails, record the error and support conditions rather than converting it into a zero-throughput benchmark.

Keep latency distributions, completed I/O and observed CPU work alongside bandwidth. Verify that the compared runs used equivalent ranges and access patterns. A synchronous engine or unsupported option may prevent the requested concurrency from being achieved, weakening a comparison based only on the configured queue depth.

Relate the result to the application

A model loader may benefit from a warm page cache in normal operation. That is a legitimate application condition, provided it is labeled. Publish separate buffered and direct results with their preparation history and measured scope. The useful decision is which observed path represents the intended deployment and which remaining question needs a different test, not which unlabeled number looks largest.

The saved job also makes changes after an I/O-engine or filesystem update visible. Recheck its conditions before comparing new numbers with an earlier observation series.

← All articles