Page Cache vs Buffer Cache: What Is the Difference?
Page cache vs buffer cache explained — indexing, the historical split, and how Linux 2.4+ unified them into one cache.
Expected Interview Answer
The page cache caches file contents in memory indexed by file and byte offset (used for regular file reads, writes, and mmap()), while the buffer cache historically caches raw disk blocks indexed by device and block number for lower-level, unstructured I/O; on modern Linux the two have been merged so buffers are simply pages managed within the unified page cache.
In older Unix designs, the two caches were genuinely separate: the page cache held file-backed memory pages keyed by (inode, offset), serving read()/write() and mmap() traffic at the virtual-memory level, while the buffer cache held raw disk blocks keyed by (device, block number), serving lower-level filesystem metadata I/O like inode tables and superblocks. This duplication meant the same physical data — say, a file block also cached as part of a memory-mapped page — could exist in RAM twice, wasting memory and risking inconsistency between the two views. Since Linux kernel 2.4, the buffer cache was merged into the page cache: a disk block’s buffer_head structure now just points into a page that lives in the unified page cache, so reading a file’s data via read() and mapping the same file via mmap() reference the exact same physical page instead of two copies. In modern interviews, the key point to make is that block-level buffers still exist as a bookkeeping structure (buffer_head) attached to pages, but the actual caching pool, eviction, and writeback logic is unified under the page cache.
- Explains the historical duplication problem the merge solved
- Clarifies why read() and mmap() on the same file share one cached copy today
- Distinguishes indexing by (inode, offset) versus (device, block number)
- Common OS interview question that tests kernel evolution knowledge
AI Mentor Explanation
The page cache is like a broadcaster’s shot-by-shot highlight reel indexed by match and minute, while the older buffer cache was like a separate technician’s raw-tape-reel index by camera and timecode — the same footage could exist twice under two different filing systems. Modern broadcast centers merged these into one indexed archive, so pulling up a highlight by match-minute and pulling the raw tape by timecode both point at the exact same stored footage instead of two separate copies sitting in storage.
Step-by-Step Explanation
Step 1
Historical split
The page cache indexed file-backed pages by (inode, offset); the buffer cache indexed raw disk blocks by (device, block number).
Step 2
Duplication problem
The same physical data could be cached twice — once as a file page, once as a raw block — wasting RAM and risking inconsistency.
Step 3
Kernel 2.4 unification
Linux merged the buffer cache into the page cache, so a buffer_head now points into a page owned by the unified cache.
Step 4
Result today
read(), write(), and mmap() on the same file all reference one shared cached page, with a single writeback and eviction path.
What Interviewer Expects
- Correctly distinguishing indexing by (inode, offset) vs (device, block number)
- Naming the duplication problem the historical split created
- Knowledge that Linux 2.4+ unified the two into a single page cache
- Understanding that read()/mmap() on the same file now share one cached copy
Common Mistakes
- Claiming the two caches are still fully separate on modern Linux
- Confusing this distinction with CPU hardware cache levels (L1/L2/L3)
- Not knowing which structure (buffer_head) still exists as bookkeeping post-merge
- Assuming the merge means block-level metadata caching disappeared entirely
Best Answer (HR Friendly)
“Historically, operating systems kept two separate memory caches — one for whole file contents (the page cache) and one for raw disk chunks (the buffer cache) — which meant the same data could sometimes be stored in memory twice. Modern Linux merged them into a single unified cache, so whether you are reading a file normally or memory-mapping it, you are working with the exact same cached copy in RAM, which saves memory and keeps everything consistent.”
Code Example
#include <fcntl.h>
#include <sys/mman.h>
#include <unistd.h>
int main(void) {
int fd = open("shared.dat", O_RDWR);
char buf[4096];
read(fd, buf, 4096);
/* populates a page in the unified page cache */
void *map = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
/* maps the SAME cached page -- no separate buffer-cache copy on modern Linux */
/* writes through map[] and future read() calls both see one consistent copy */
munmap(map, 4096);
close(fd);
return 0;
}Follow-up Questions
- What kernel version unified the page cache and buffer cache in Linux?
- What is a buffer_head and does it still exist today?
- Why did the old split risk data inconsistency?
- How does mmap() benefit from the unified page cache?
MCQ Practice
1. Historically, how was the buffer cache indexed?
The buffer cache indexed raw disk blocks by (device, block number), unlike the page cache which indexed by (inode, offset).
2. What problem did the old separate-cache design create?
A file block accessed both via read() and via a raw block reference could be duplicated in two separate caches.
3. What changed in Linux kernel 2.4 regarding these caches?
Since Linux 2.4, buffer_head structures point into pages owned by the unified page cache rather than a separate buffer cache pool.
Flash Cards
How did the page cache index data historically? — By (inode, offset) for file-backed pages.
How did the buffer cache index data historically? — By (device, block number) for raw disk blocks.
What problem did having both caches separately cause? — The same data could be duplicated in memory, wasting RAM and risking inconsistency.
What happened in Linux 2.4 and later? — The buffer cache was merged into the page cache into one unified caching layer.