How OS Disk Caching Skews Storage Read Benchmarks

Operating system disk caching significantly impacts hardware benchmarking by temporarily storing data in fast system memory (RAM) rather than reading it directly from the storage drive. While this feature is designed to boost everyday computer performance, it severely skews storage read tests by measuring the speed of the system's RAM instead of the actual hard drive or solid-state drive (SSD). This article explains the mechanics of operating system disk caching, how it invalidates storage benchmark results, and the methods used to bypass it for accurate hardware testing.

What is Operating System Disk Caching?

Modern operating systems, including Windows, macOS, and Linux, utilize unused system RAM as a buffer for storage devices. This is often referred to as the "page cache" or "file system cache." Because RAM is exponentially faster than any SSD or mechanical hard drive, the operating system keeps copies of recently created, read, or modified files in this memory space. When an application requests that data again, the OS delivers it instantly from the RAM rather than waiting for the slower storage drive to retrieve it.

How the Cache Interferes with Read Tests

Standard storage benchmarks measure performance by generating a temporary test file, writing it to the target drive, and then reading that file back to measure the read speed. Operating system disk caching breaks this process through the following sequence:

  1. The Write Phase: The benchmarking software creates a test file (e.g., a 1GB file) and writes it to the storage drive.
  2. The Interception: As the file is written to the drive, the operating system simultaneously keeps a copy of that 1GB file in the system's unused RAM.
  3. The Read Phase: The benchmark software immediately requests to read that 1GB file back to calculate the drive's read speed.
  4. The False Result: Recognizing that the requested file is already sitting in the page cache, the operating keys in on the RAM copy. The storage drive is completely bypassed.

The Impact on Benchmark Scores

When a benchmark reads from the OS cache instead of the physical drive, the resulting data is entirely invalid for hardware evaluation.

For example, a standard SATA SSD has a physical hardware limit of roughly 550 MB/s to 600 MB/s. A high-end PCIe 4.0 NVMe SSD typically maxes out around 7,000 MB/s to 7,500 MB/s. However, DDR4 and DDR5 system RAM can easily transfer data at speeds ranging from 25,000 MB/s to over 60,000 MB/s. If the OS cache interferes, a benchmark on a budget SATA SSD might report read speeds of 30,000 MB/s. The test is no longer benchmarking the storage drive; it is benchmarking the system memory.

How to Bypass Disk Caching for Accurate Results

To get true hardware read speeds, the benchmarking software or the user must force the operating system to read directly from the physical storage medium. There are three primary methods to achieve this:

1. Using Direct I/O

Professional benchmarking utilities (such as CrystalDiskMark, FIO, and Iometer) use specific programming flags to bypass the OS cache. In Windows, software uses the FILE_FLAG_NO_BUFFERING flag, while Linux utilities use the O_DIRECT flag. These instructions explicitly command the operating system not to cache the test data in RAM, guaranteeing that all read requests hit the physical drive.

2. Exceeding System RAM Capacity

If a benchmarking tool does not support Direct I/O, the user can defeat the cache by brute force. If a computer has 16GB of RAM, it is physically impossible for the OS to cache a 32GB test file. By setting the benchmark's test file size to be significantly larger than the total installed system memory, the cache overflows, forcing the system to read the data directly from the storage drive.

3. Flushing the Cache Manually

In scripted or custom testing environments, testers separate the write and read phases. First, the test file is written to the drive. Next, the tester issues a system command to flush (clear) the OS page cache from the RAM. Finally, the read test is executed. Because the RAM has been wiped of the cached data, the OS has no choice but to pull the file directly from the storage hardware.