---
title: "A Cached File Read Is Not an SSD Throughput Result"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/storage-page-cache-direct-io-measurement-boundary"
last-updated: "2026-10-20"
---

# A Cached File Read Is Not an SSD Throughput Result

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

A file reader can receive data already held in the operating system's page cache. Its returned byte count therefore need not equal new bytes supplied by an SSD. A useful storage comparison identifies where the bytes were counted, which reads the result includes and which cache boundary the actual I/O path bypassed. A cache-assisted application result can be valuable without establishing SSD-interface throughput or NAND activity.

## Locate the cache between the application and storage

Start with what the reported byte count describes. Linux's read(2) interface returns the number of bytes delivered into the caller's buffer. That application-facing count does not identify the physical source of each returned byte. If a report instead counts data processed from buffers the application already holds, clarify whether its number represents new file reads at all.

The Linux 6.18 Page Cache introduction states that normal filesystem reads, writes and memory mappings use the page cache. Its memory-management overview explains the purpose: retaining file data in memory can avoid disk access on subsequent reads. The buffer in which an application receives data and the kernel's cached file data are separate locations.

For a read needing data from backing storage, the filesystem and its storage path must obtain the missing data. For a read satisfied by the page cache, the application can receive the requested file contents without another transfer of those contents from the backing device. Successful file access establishes that the reader received data; it does not establish a fresh device read.

Keep the layers visible: application buffers, the operating-system page cache, the backing block device or remote storage service, and any controller memory and media below that service. The actual implementation determines which layers exist. Naming the bottom layer in a proposal does not move an application counter to that layer.

References: [M1](https://man7.org/linux/man-pages/man2/read.2.html), [K1](https://docs.kernel.org/6.18/mm/page_cache.html), [K2](https://docs.kernel.org/6.18/admin-guide/mm/concepts.html)

## Count two passes through one 8 GiB file

Consider one unchanged 8 GiB file in a filesystem backed by one SSD. Define the storage boundary as read-data payload returned across that SSD's host-facing interface. This counts file data, rather than protocol overhead or internal NAND traffic. Stipulate two complete passes using ordinary buffered file reads, with no application-private copy supplying the second pass.

On the first pass, all 8 GiB comes from the identified SSD boundary and remains in the operating system's page cache. On the second pass, all 8 GiB is served from that page cache. Assume no read-ahead, background I/O or extra traffic in this toy case. These are stipulated conditions, not observations from a system.

The first pass delivers 8 GiB to the application and receives 8 GiB from the SSD boundary. The second delivers another 8 GiB to the application and receives 0 GiB from that boundary. Across both passes, the application receives 16 GiB while the SSD supplies 8 GiB.

No elapsed time is supplied, so the example establishes neither a GiB/s result nor a performance ratio. If a report divided the application's 16 GiB by its measured interval, its numerator would still describe application reads. Reusing that numerator as SSD-transferred bytes would change the claim. Even the stipulated 8 GiB returned by the SSD does not identify how those bytes were obtained inside the drive.

References: [K1](https://docs.kernel.org/6.18/mm/page_cache.html), [K2](https://docs.kernel.org/6.18/admin-guide/mm/concepts.html)

## Identify the actual direct-I/O bypass

Direct I/O can bypass the Linux page cache, but the relevant claim concerns a particular path. The O_DIRECT description concerns file I/O to or from user-space buffers. The manual documents filesystem, file and kernel differences, including circumstances that fail or fall back to buffered I/O.

For a supplied result, distinguish the requested mode from the behavior established for the reads being reported. A selected option or a direct-I/O label is an input to the interpretation. It does not explain by itself whether every covered read followed the expected path on the actual implementation.

The useful question for the responsible software or storage evaluator is which cache was bypassed and what evidence establishes that behavior for the stated workload. Changing the mode also changes the path being evaluated. Its result should answer the corresponding storage question rather than automatically replace evidence for the application's intended buffered path.

References: [K1](https://docs.kernel.org/6.18/mm/page_cache.html), [M2](https://man7.org/linux/man-pages/man2/open.2.html)

## Look below the client page cache

For NFS, the manual makes the location explicit: direct I/O bypasses the client page cache, but the protocol does not pass the flag to the server. The server may still cache the I/O. Evidence that a client fetched data from a server therefore need not establish that the server fetched it anew from its drives.

Caching can also exist within the storage equipment. Dell's PERC 11 guide provides a concrete example: its documented read-ahead behavior stores additional data in controller cache memory in anticipation of later requests. That is a different location from the client's Linux page cache. It illustrates an additional layer to identify, without assigning that controller or cache policy to an unspecified NVMe system.

Below the host-facing interface, an SSD's controller, internal memory and NAND media remain another boundary. A payload count at that interface observes what the SSD returned, rather than every operation inside it. Calling the result a fresh NAND-only measurement needs additional product-specific evidence. Bypassing the client page cache cannot establish that internal behavior.

References: [M2](https://man7.org/linux/man-pages/man2/open.2.html), [D1](https://www.dell.com/support/manuals/ja-jp/perc-h755/perc11_ug/virtual-disk-read-cache-policy?guid=guid-0e301012-1467-49e9-bb66-da85cb764382&lang=en-us)

## Keep other meanings of direct separate

Page-cache bypass does not establish a GPU-memory destination. NVIDIA's September 17, 2026 GPUDirect Storage Design Guide describes a direct DMA path between storage and GPU memory that avoids a CPU-memory bounce buffer. That is a separate data-movement claim. A direct file-read label alone establishes neither that GPU path nor elimination of every intermediate copy.

Nor does O_DIRECT alone supply O_SYNC's data-and-metadata completion guarantees. A read-performance report consequently cannot establish write durability or power-loss protection. The related GDS and SSD protection articles cover those separate decisions; neither needs to be inferred from a cached-read comparison.

References: [N1](https://docs.nvidia.com/gpudirect-storage/design-guide/index.html), [M2](https://man7.org/linux/man-pages/man2/open.2.html)

## Compare the result being purchased

A buyer may need evidence for repeated application reads, for data arriving at a storage-service boundary, or for payload returned by a selected SSD. Decide which question matters before ranking the numbers. Cache reuse can be part of the intended workload and a useful reason for an application to finish sooner. Removing that reuse from the evaluation would answer a different question.

A cache-warm result is applicable only to the reuse conditions it represents. It does not establish the time needed to fetch an uncached dataset or the result for a working set with different reuse. Conversely, evidence from a path that bypasses the page cache does not automatically predict the application's buffered-read experience. These are limits on transferring a result between conditions, rather than a reason to reject caching.

Return to the two-pass example when reading a report. Does its interval include the first fetch and the repeat, or only the repeat? Does the byte total represent the application's file reads or the SSD's returned payload? Identical filenames and hardware cannot resolve those questions. A report covering only the second pass leaves the initial storage fetch outside its evidence.

Ask the provider to explain the data population, prior-read history and relevant cache state alongside the actual filesystem, kernel and achieved I/O path. For an SSD-throughput claim, the supporting byte evidence must address the identified SSD boundary. For shared storage, distinguish client-to-server data from the server's backing-device data. An unexplained difference between those counts is a question to resolve, rather than a reason to substitute one count for another.

Keep the chosen boundary attached when comparing the reported rate. The existing IOPS, throughput and latency guide explains request sizes, concurrency and response statistics. Those conditions still matter, but matching them does not repair a numerator taken from the wrong layer.

References: [K2](https://docs.kernel.org/6.18/admin-guide/mm/concepts.html), [M2](https://man7.org/linux/man-pages/man2/open.2.html)

## Connect the selected storage to physical work

When the selected storage creates a cabling project, Leviathan's Structured Cabling & Fiber Installation service is relevant to the approved physical connections, routing, dressing, labels and agreed connection records. A connection record identifies the installed path; it does not establish which cache supplied an application's data.

Use the related service and project-inquiry links with a nonconfidential equipment summary, site location, approved endpoint and patching requirements, appointed materials supplier and required physical handoff. Storage configuration, I/O-path verification and performance evaluation remain with separately appointed storage and software specialists.

References: [L1](https://www.leviathansystems.co/services/structured-cabling)

## Primary sources

- [K1 — Linux 6.18 documentation: Page Cache](https://docs.kernel.org/6.18/mm/page_cache.html). Checked 2026-10-20. Identifies the page cache in normal filesystem I/O and the possibility of bypassing it with direct I/O.
- [K2 — Linux 6.18 memory-management concepts: Page cache](https://docs.kernel.org/6.18/admin-guide/mm/concepts.html). Checked 2026-10-20. Explains retaining file data in memory to avoid later disk accesses. Supports the read-reuse mechanism; no cache-residency prediction is supplied.
- [M1 — Linux man-pages 6.19: read(2)](https://man7.org/linux/man-pages/man2/read.2.html). Checked 2026-10-20. Description and return-value sections define delivery into the caller's buffer and returned byte count.
- [M2 — Linux man-pages 6.19: open(2), O_DIRECT description and notes](https://man7.org/linux/man-pages/man2/open.2.html). Checked 2026-10-20. Implementation-dependent direct I/O, NFS client/server caching distinction and the separate O_SYNC guarantees.
- [D1 — Dell PERC 11 User's Guide: Virtual disk read cache policy](https://www.dell.com/support/manuals/ja-jp/perc-h755/perc11_ug/virtual-disk-read-cache-policy?guid=guid-0e301012-1467-49e9-bb66-da85cb764382&lang=en-us). Checked 2026-10-20. English topic documents controller read-ahead caching for the named PERC family. Used only to locate a cache below the client, without recommending a policy.
- [N1 — NVIDIA GPUDirect Storage Design Guide](https://docs.nvidia.com/gpudirect-storage/design-guide/index.html). Checked 2026-10-20. September 17, 2026 guide, introduction and data-transfer discussion. Distinguishes GPU-memory DMA and CPU-memory staging from a page-cache bypass claim.
- [L1 — Leviathan Systems: Structured Cabling & Fiber Installation](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Public physical installation and connection-record scope, conditional on approved requirements, material responsibilities and project availability.

## Related Leviathan resources

- [Compare storage IOPS, throughput and latency at the same boundary](/articles/gpu-storage-iops-throughput-latency-comparison)
- [Distinguish a GPUDirect Storage path from compatible file I/O](/articles/gpudirect-storage-direct-path-versus-compatible-io)
- [Locate the write population covered by SSD power-loss protection](/articles/gpu-ssd-power-loss-protection-cache-nand)
- [Separate DGX B200 local cache from the dataset service](/articles/b200-deployment-guide)
- [Trace the storage-facing physical connections](/articles/gpu-storage-network-physical-handoff)
- [Discuss structured cabling and physical connection records](/services/structured-cabling)
- [Send a nonconfidential cabling project outline](/contact?service=structured-cabling&from=%2Farticles%2Fstorage-page-cache-direct-io-measurement-boundary)

## Define the physical connections for your storage project

Share the equipment summary, approved endpoints and required handoff so we can discuss the cabling scope, site requirements and availability.

[Discuss the scope](/contact?service=structured-cabling&from=/articles/storage-page-cache-direct-io-measurement-boundary)