What are Memory-Mapped Files?
Learn how memory-mapped files work — mmap(), lazy page loading, MAP_SHARED vs MAP_PRIVATE — with an OS interview question answered.
Expected Interview Answer
A memory-mapped file is a file whose contents are mapped directly into a process’s virtual address space via the page cache, so the program reads and writes the file using ordinary memory instructions instead of explicit read() and write() system calls.
When a process calls mmap() on a file descriptor, the kernel creates page table entries pointing at the file’s pages in the page cache, but does not actually load data from disk yet — the mapping is lazy. The first access to a mapped page triggers a page fault, at which point the kernel reads that page from disk into the page cache and completes the mapping, after which subsequent accesses are as fast as normal memory reads. Writes to a shared (MAP_SHARED) mapping dirty the underlying page cache page, and the kernel flushes dirty pages back to disk asynchronously or on msync()/munmap(). This avoids an extra copy between kernel buffers and user buffers that a read() call would incur, makes random access to large files cheap since only touched pages are ever loaded, and lets multiple processes share the same physical pages when they map the same file.
- Avoids the extra copy between kernel and user buffers that read() incurs
- Loads only the pages actually touched, ideal for large files with sparse access
- Lets multiple processes share physical pages by mapping the same file
- Turns file I/O into ordinary pointer/array access for simpler code
AI Mentor Explanation
Memory-mapped files are like a stadium giving every ticket holder a seat number tied directly to a master seating plan instead of issuing a fresh physical ticket booklet for every match. A spectator only occupies the actual seat resource the moment they walk in and sit down (the page fault triggering the disk read), rather than the stadium pre-printing every seat in advance. Because two friends holding tickets to the same block share the very same physical seats, changes one makes (moving a chair) are visible to the other, mirroring how two processes mapping the same file share physical pages.
Step-by-Step Explanation
Step 1
Call mmap()
The process maps a file descriptor into its virtual address space; the kernel creates page table entries but loads nothing yet.
Step 2
First access page fault
Touching a mapped address triggers a page fault since the page is not yet resident.
Step 3
Page cache fill
The kernel reads the corresponding file page from disk into the page cache and wires it into the process page table.
Step 4
Writeback
For shared mappings, dirtied pages are flushed back to disk asynchronously or via msync()/munmap().
What Interviewer Expects
- A clear definition tying mmap() to page-fault-driven lazy loading
- Understanding that mmap() avoids the kernel-to-user buffer copy of read()
- Awareness of MAP_SHARED vs MAP_PRIVATE semantics
- A concrete use case such as large sparse files or inter-process shared memory
Common Mistakes
- Thinking mmap() loads the whole file into RAM immediately
- Confusing MAP_SHARED (writes propagate to the file) with MAP_PRIVATE (copy-on-write, writes stay local)
- Forgetting that a mapped file can trigger a SIGBUS if the file shrinks after mapping
- Not knowing that dirty pages need msync() for a guaranteed durability point
Best Answer (HR Friendly)
“Memory-mapped files let a program treat a file on disk as if it were just a chunk of memory it can read and write directly, instead of calling separate read and write functions. The operating system quietly loads only the parts of the file that are actually touched, which makes big files fast to work with and lets different programs share the same data in memory.”
Code Example
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
int fd = open("data.bin", O_RDWR);
off_t size = lseek(fd, 0, SEEK_END);
char *map = mmap(NULL, size, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, 0);
close(fd); /* mapping stays valid after fd is closed */
map[0] = 'X'; /* ordinary memory write, dirties the page cache page */
msync(map, size, MS_SYNC); /* force the write back to disk */
munmap(map, size);Follow-up Questions
- What is the difference between MAP_SHARED and MAP_PRIVATE?
- How does mmap() avoid the extra copy that read() performs?
- What happens if a mapped file is truncated by another process?
- How would you use mmap() to implement shared memory between two processes?
MCQ Practice
1. When does the actual disk read for a memory-mapped file page happen?
mmap() sets up page table entries lazily; the real disk read is deferred until a page fault occurs on first access.
2. What is a key advantage of mmap() over read()/write()?
Memory-mapped I/O lets the process access the page cache directly, skipping the copy that read()/write() perform into a separate user buffer.
3. Which mapping type propagates writes back to the underlying file?
MAP_SHARED writes dirty the page cache pages backing the file, which are eventually flushed to disk; MAP_PRIVATE writes are copy-on-write and stay local.
Flash Cards
What is a memory-mapped file? — A file whose contents are mapped into a process’s address space so it can be accessed with normal memory instructions.
When is a mapped page actually loaded from disk? — Lazily, on the first page fault triggered by accessing that page.
MAP_SHARED vs MAP_PRIVATE? — MAP_SHARED writes go back to the file and are visible to other mappers; MAP_PRIVATE writes are copy-on-write and stay local.
Why is mmap() often faster than read()? — It avoids the extra kernel-to-user buffer copy that read() performs.