OS Page Cache
The OS page cache keeps file pages in RAM, serving repeated reads from memory and delaying writes — transparently to applications, which must flush and persist explicitly where durability matters.
Definition
The kernel page cache stores file-backed pages in free RAM. Reads hit the cache when pages are resident; writes mark pages dirty and flush lazily via writeback or explicit fsync. The cache is shared across processes and is reclaimed under memory pressure, so resident data is a performance bonus, never a durability guarantee.
Context and scope
Affects database durability tuning (fsync semantics), file server throughput, and container memory accounting. Explains why buffered writes survive process crashes but not power loss.
Common misconceptions
- write() returned, so data is durable — write copies into the page cache; only fsync or synchronous flags push to storage
- The page cache belongs to my application — it is kernel-global; another process or reclaim can evict your warm pages
- More RAM always helps — cache effectiveness follows access pattern; scanning workloads evict useful pages no matter the size
Anti-patterns
- Treating buffered write completion as persistence and losing acknowledged writes on power failure
- Assuming mmap reads are synchronous with file changes made by other processes
- Running backups by copying files without quiescing writers and capturing torn cached state
Related concepts
Related examples
Authoritative source
What it is
The kernel turns spare RAM into a transparent cache for file contents. Applications gain read speedups and asynchronous writes without code changes — and inherit the ambiguity of not knowing which bytes are actually on disk.
How it works
Reads populate pages; dirty pages flush via writeback threads on thresholds and time. fsync flushes a file and returns after the device acknowledges. Reclamation drops clean pages instantly and must write dirty ones first, so dirty ratios are the pressure gauge. mmap maps pages directly, sharing them with the cache.
When to account for it
Database and queue durability design: WAL plus fsync discipline is meaningless without understanding what the cache already did. Capacity planning: cache size shapes repeated-read performance. Container memory: page cache accounting surprises hosts and orchestrators.
Pitfalls
Process crash preserves the page cache — data written but not fsynced survives; power loss or kernel panic does not. The distinction defines durable systems. Dirty page explosions during bursts stall writes for seconds during writeback. Direct I/O bypasses the cache entirely, and forgetting that removes double-buffering gains applications expected.