The Cache Manager

Every chapter in this level so far has treated file I/O as, eventually, a real trip to physical storage. Very often, it isn't — the Cache Manager exists specifically to make repeated reads of the same data essentially free, by borrowing the exact same paging machinery Memory management already uses for ordinary process memory.

File data, represented as memory

The Cache Manager's core idea: represent recently-accessed file data as mapped views — regions backed by the same kind of virtual-memory-and-page-fault machinery covered in Paging & page faults, rather than as a separate, purpose-built caching layer with its own memory-management logic. A cached read, underneath, is close to a memory access: if the relevant page is already resident (because it was read recently, by this process or another one entirely), it's satisfied directly from RAM; if not, it triggers essentially the same page-fault-and-fetch sequence an ordinary memory-mapped file access would.

This reuse is deliberate and consequential: it means the Cache Manager doesn't compete with the Memory Manager for physical pages as an independent, rival consumer — it is, largely, a specific application of the Memory Manager's own machinery, which is exactly why cached file data and a process's own working set (Working sets & trimming) are subject to the same overall memory-pressure and reclaim policy, rather than two separate systems fighting over the same physical RAM with no shared accounting.

The lazy writer: deferring writes safely

For writes, the Cache Manager generally doesn't force an immediate trip to disk for every single write operation — doing so would be far slower than necessary for typical usage patterns. Instead, modified cached pages are tracked and flushed back to disk asynchronously by the lazy writer, a background mechanism that writes dirty pages out on its own schedule (and more aggressively under memory pressure, or when an application explicitly requests a flush via FlushFileBuffers). This trades a small, bounded window of "data not yet physically on disk" for a large, real performance win on the common case of many small, frequent writes.

Cached I/O vs. memory-mapped I/O: related, not identical

It's worth being precise about a distinction that's easy to blur: cached I/O (ordinary ReadFile/WriteFile calls, which the Cache Manager transparently accelerates using the mechanism above) and memory-mapped I/O (an application explicitly calling MapViewOfFile to treat file content as directly-addressable memory) are related in mechanism but different in what the application-level programming model actually looks like and what guarantees it makes. Both ultimately lean on the same underlying page-based machinery, but conflating "my reads are cached" with "my file is memory-mapped" glosses over real differences in API surface and in exactly when writes become visible to other readers.

A worked example: reading the same file twice

An application that reads a file, closes it, and reads it again shortly afterward will very often find the second read dramatically faster — not because the storage device got faster, but because the relevant pages are still resident from the first read, satisfied directly from memory with no device access at all. This is precisely why storage benchmarks have to be careful about cache effects: measuring "disk read speed" by reading the same file repeatedly, without deliberately bypassing or clearing the cache, mostly measures memory bandwidth instead.

A common mistake

Attributing every performance observation about file I/O directly to disk speed, without considering caching, routinely leads to wrong conclusions — "this app is fast because it has a great disk" is very often, in reality, "this app is fast because the data it needs is already cached in RAM from a previous access," a completely different and less durable explanation (it degrades the moment memory pressure evicts that cached data, or the first time genuinely new data is accessed).

Where this connects

• Paging & page faults is the exact machinery the Cache Manager reuses to serve cached reads.
• Working sets & trimming is what determines how long cached file data actually stays resident under competing memory pressure.