What is the Buffer Cache in an Operating System?
Learn what the buffer cache is, how write-back caching and fsync() work, and how it relates to the page cache in Linux.
Expected Interview Answer
The buffer cache is a region of kernel memory that holds recently used raw disk blocks so that repeated reads and writes to the same block hit fast RAM instead of a slow physical disk, and writes can be batched and flushed asynchronously rather than committed synchronously on every call.
When a process issues a block-level I/O request, the kernel first checks the buffer cache for that block; on a hit, data is copied directly from memory, and on a miss, the kernel schedules a disk read, stores the fetched block in the cache, and serves it from there for any subsequent access. Writes are typically written into a cache buffer first and marked dirty, then flushed to disk later by a background writeback daemon (or on an explicit sync/fsync call), which lets the OS coalesce many small writes into fewer, larger disk operations. Historically the buffer cache was a separate structure from the page cache used for file-backed memory mappings, indexed by device and block number rather than by file and offset, though modern Unix-like kernels such as Linux have unified the two so that block buffers are just pages tracked within the page cache. Understanding the buffer cache explains why a crash right after a write can lose data that was never fsync()'d, and why disk-heavy workloads benefit enormously from having spare RAM available for caching.
- Explains why repeated disk reads of the same block are fast after the first access
- Clarifies write-back batching and why fsync() matters for durability
- Distinguishes the historical buffer cache from the (now unified) page cache
- Motivates RAM sizing decisions for I/O-heavy server workloads
AI Mentor Explanation
The buffer cache is like a scorer keeping the last several overs’ ball-by-ball details on a handy notepad instead of walking to the archive room every time someone asks about a recent delivery. If the requested ball is on the notepad, the answer comes back instantly; if not, the scorer fetches it from the archive and jots it on the notepad for next time. Corrections made on the notepad are only copied into the official archive periodically, which is why a sudden power cut before that copy-over can lose the latest notepad edits.
Step-by-Step Explanation
Step 1
I/O request issued
A process requests a disk block via read() or write(), routed through the block I/O layer.
Step 2
Cache lookup
The kernel checks the buffer cache, indexed by device and block number, for that block.
Step 3
Hit or miss handling
On a hit, data is served straight from memory; on a miss, the kernel schedules a disk read and populates the cache.
Step 4
Deferred writeback
Writes mark the buffer dirty and return quickly; a background daemon (or fsync()) later flushes dirty buffers to disk.
What Interviewer Expects
- A clear description of caching disk blocks in RAM to avoid repeated slow I/O
- Understanding of write-back (dirty buffer) behavior versus write-through
- Awareness that unflushed writes can be lost on a crash unless fsync() is used
- Knowledge that Linux has unified the buffer cache into the page cache
Common Mistakes
- Claiming every write() call is immediately durable on disk
- Confusing the buffer cache with CPU hardware caches (L1/L2/L3)
- Not knowing that fsync()/sync() is needed to force durability
- Treating the buffer cache and page cache as still fully separate on modern Linux
Best Answer (HR Friendly)
“The buffer cache is a chunk of memory the operating system uses to hold recently read or written disk data, so the next time that same data is needed, it comes from fast RAM instead of a slow physical disk. Writes are often collected in this cache and written to disk a bit later in batches, which is efficient but means an unexpected crash can lose the very last changes if they were not explicitly flushed first.”
Code Example
#include <fcntl.h>
#include <unistd.h>
int main(void) {
int fd = open("important.log", O_WRONLY | O_CREAT, 0644);
write(fd, "transaction committed\n", 22);
/* data sits in the kernel buffer cache (dirty), not guaranteed on disk yet */
fsync(fd);
/* forces the dirty buffer to be flushed to physical storage before returning */
close(fd);
return 0;
}Follow-up Questions
- What is the difference between fsync() and fdatasync()?
- How does the OS decide when to flush dirty buffers automatically?
- How did Linux unify the buffer cache with the page cache?
- What risks does write-back caching introduce for database durability?
MCQ Practice
1. What does the buffer cache primarily store?
The buffer cache holds recently accessed disk blocks in RAM so repeated I/O to the same block avoids the physical disk.
2. What happens to a write() call under typical write-back caching?
Write-back caching writes into memory first and returns quickly, deferring the actual disk write to a background flush or explicit sync.
3. What is the risk of unflushed dirty buffers?
Because dirty buffers only exist in RAM until flushed, a crash before that flush loses the unwritten changes.
Flash Cards
What is the buffer cache? — Kernel memory holding recently used disk blocks to speed up repeated I/O.
What does a “dirty” buffer mean? — A cached block that has been modified but not yet written back to disk.
How do you force a flush to disk? — Call fsync() or fdatasync() on the file descriptor, or sync() system-wide.
How does modern Linux relate the buffer cache to the page cache? — They are unified — block buffers are tracked as pages within the page cache.