Understanding Memory-Mapped File Algorithms: System Performance

1. Introduction and Core Concepts

Memory-mapped file algorithms represent a fundamental bridge between virtual memory management and persistent storage, allowing applications to treat files on disk as if they were contiguous blocks of RAM. Instead of issuing explicit read() and write() system calls to move data between disk and user-space buffers, a memory-mapped file is mapped directly into a process's virtual address space. Once mapped, the operating system handles data movement transparently through its paging subsystem, loading pages on demand and writing dirty pages back to disk asynchronously.

At its core, the concept relies on the virtual memory abstraction provided by modern operating systems. Every process operates in its own virtual address space, which the kernel maps to physical RAM and, when necessary, to swap or file-backed pages. When you create a memory mapping with a system call like mmap on POSIX systems or CreateFileMapping on Windows, you are instructing the kernel to associate a range of virtual addresses with a file's contents. Accessing those addresses triggers page faults that the kernel resolves by fetching the corresponding file blocks, making I/O appear as simple memory dereferences.

Understanding memory-mapped file algorithms is critical for system performance because they eliminate many of the traditional overheads of file I/O. There is no need for double buffering where data is first copied into kernel buffers and then into user buffers. There is no need for explicit lseek and read loops for random access. Perhaps most importantly, memory-mapped files enable the operating system's highly optimized page cache and prefetching logic to be reused automatically, and they allow multiple processes to share the same physical pages for the same file, dramatically reducing memory consumption and improving inter-process communication latency. For workloads involving large datasets, random access, or shared data, the performance difference can be orders of magnitude.

Why Memory Mapping Matters for Performance

Traditional file I/O is system-call heavy. Each read or write requires a context switch from user mode to kernel mode, parameter validation, and a data copy. For small, frequent accesses, this overhead dominates execution time. Memory-mapped access, by contrast, incurs the cost of a page fault only on the first access to a page (typically 4KB). Subsequent accesses to the same page are pure memory operations at RAM speed, with no system call at all. This makes memory-mapped file algorithms exceptionally efficient for algorithms that exhibit locality of reference or require fine-grained random access.

Furthermore, memory mapping integrates seamlessly with the OS virtual memory manager's eviction and write-back policies. When physical memory is under pressure, clean mapped pages can be discarded without I/O because the file already contains the data. Dirty pages are flushed lazily by background kernel threads (like pdflush on Linux), which can batch writes more efficiently than user-space code. This lazy, demand-paged behavior is the essence of why memory-mapped file algorithms are considered a cornerstone of high-performance system design.

2. How It Works

The mechanism behind memory-mapped files is demand paging. When a file is mapped, no data is immediately loaded into RAM. The kernel simply creates a set of page table entries in the process's virtual memory area (VMA) and marks them as invalid or not present. It records that this virtual range is backed by a specific file, offset, and length. The actual physical frames remain unallocated until they are needed.

When the program accesses an address within the mapped region for the first time, the CPU's Memory Management Unit (MMU) detects that the page table entry is not present and raises a page fault exception. Control transfers to the kernel's page fault handler, which identifies that the faulting address belongs to a file-backed mapping. The handler then allocates a free physical page frame, issues a disk I/O request to read the corresponding 4KB (or larger) chunk from the file, fills the frame, updates the page table to point to it, and returns to user space. The faulting instruction is then retried and succeeds as if the data had always been in memory.

Writes work through a similar but slightly more complex path. If the mapping is created with write permission (MAP_SHARED), a write to the mapped memory marks the physical page as dirty in the page table. The kernel does not immediately write the page back to disk. Instead, the dirty page remains in the page cache until the kernel decides to flush it, either because of memory pressure, a periodic sync, or an explicit call to msync() or munmap(). If the mapping is MAP_PRIVATE, the kernel uses copy-on-write: the first write to a page triggers a private copy of that page for the process, leaving the original file and other processes' views unaffected.

Virtual Memory, Page Cache, and TLB Interaction

A key performance advantage is that memory-mapped files leverage the unified page cache. On Linux, there is no separate buffer cache for file I/O and memory for mappings; they are the same. This means if one process reads a file via traditional I/O and another maps the same file, they share the same cached pages in RAM. The Translation Lookaside Buffer (TLB), which caches virtual-to-physical translations, also accelerates repeated accesses. After the first fault, subsequent accesses hit in the TLB and proceed at full memory speed.

The kernel also performs read-ahead and prefetching automatically. When it detects sequential access patterns through page faults, it will speculatively read ahead subsequent pages from disk before they are faulted. This hides disk latency and is far more effective than manual read-ahead implemented in user space, because the kernel has global knowledge of I/O scheduling and can merge requests efficiently.

Synchronization and Consistency

Because the mapping is shared between the page cache and user memory, consistency is a critical consideration. Changes made through the mapping are immediately visible to other processes mapping the same file with MAP_SHARED, as they share the same physical pages. However, durability is not guaranteed until msync or fsync is called. Algorithms must carefully decide when to enforce persistence versus when to allow lazy write-back for maximum throughput.

3. Implementation

Python exposes memory-mapped files through the standard library mmap module, which provides a file-like and sequence-like interface over an OS-level mapping. The object behaves like a mutable byte array but is backed by the file on disk, allowing efficient slicing, searching, and random access without loading the entire file into Python heap memory.

import mmap
import os

# Create a sample file for demonstration
FILE_PATH = "example.dat"
DATA = b"Hello, memory-mapped world! " * 1000

with open(FILE_PATH, "wb") as f:
    f.write(DATA)

# Example 1: Basic read-only memory mapping
# This maps the entire file into virtual memory without loading it all at once
with open(FILE_PATH, "r+b") as f:
    # length=0 means map the entire file
    # access=ACCESS_READ provides read-only view (page protection)
    with mmap.mmap(f.fileno(), length=0, access=mmap.ACCESS_READ) as mm:
        # mm behaves like bytes - no explicit read() syscall needed
        print(f"File size: {len(mm)} bytes")
        print(f"First 30 bytes: {mm[:30]}")
        
        # Random access is O(1) - triggers page fault only on first touch
        print(f"Byte at offset 5000: {mm[5000]}")
        
        # Efficient searching without loading file - uses optimized memchr
        pos = mm.find(b"world")
        print(f"Found 'world' at offset: {pos}")

# The OS automatically unmaps and releases pages on context exit

import mmap
import re

# Example 2: Random access and in-place modification with MAP_SHARED semantics
FILE_PATH = "records.dat"
RECORD_SIZE = 64
NUM_RECORDS = 10000

# Create a file with fixed-size records
with open(FILE_PATH, "wb") as f:
    f.write(b"\x00" * RECORD_SIZE * NUM_RECORDS)

with open(FILE_PATH, "r+b") as f:
    # ACCESS_WRITE creates a MAP_SHARED mapping - writes go back to file
    with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_WRITE) as mm:
        # Write a record at index 5000 with direct memory assignment
        # No seek() or write() needed - just calculate offset
        record_index = 5000
        offset = record_index * RECORD_SIZE
        payload = f"RECORD-{record_index:05d}".encode().ljust(RECORD_SIZE, b"-")
        
        # This assignment marks the page dirty; kernel will flush lazily
        mm[offset:offset + RECORD_SIZE] = payload
        
        # Reading back is immediate - same physical page
        read_back = mm[offset:offset + RECORD_SIZE]
        print(f"Wrote and read back: {read_back[:20]}")
        
        # Efficient iteration over large file using memory view
        # This is ideal for algorithms needing strided or random access
        for i in range(0, len(mm), RECORD_SIZE * 1000):
            # Only touched pages are faulted in
            if mm[i:i+6] == b"RECORD":
                print(f"Found record header at {i}")
                break
        
        # Ensure durability - flush dirty pages to disk synchronously
        mm.flush()  # Equivalent to msync(MS_SYNC)

import mmap
import os
import struct

# Example 3: Processing a large binary dataset > RAM size
# Simulates an array of 64-bit integers stored on disk
FILE_PATH = "large_array.bin"
NUM_ELEMENTS = 10_000_000  # ~80 MB
FORMAT = "q"  # signed 8-byte integer
ELEMENT_SIZE = struct.calcsize(FORMAT)

# Create file if not exists (sparse file optimization)
if not os.path.exists(FILE_PATH):
    with open(FILE_PATH, "wb") as f:
        # Seek and write one byte to create sparse file of desired size
        f.seek(NUM_ELEMENTS * ELEMENT_SIZE - 1)
        f.write(b"\x00")

with open(FILE_PATH, "r+b") as f:
    with mmap.mmap(f.fileno(), 0) as mm:
        # Memory-map allows treating 80MB file as an array
        # without allocating 80MB in Python heap
        
        # Write pattern: set every 1M-th element
        for idx in range(0, NUM_ELEMENTS, 1_000_000):
            offset = idx * ELEMENT_SIZE
            # Pack integer directly into mapped memory
            mm[offset:offset+ELEMENT_SIZE] = struct.pack(FORMAT, idx * 2)
        
        # Compute sum via sequential scan - OS read-ahead helps here
        total = 0
        # Use memoryview to avoid copying bytes on slice
        mv = memoryview(mm)
        for idx in range(NUM_ELEMENTS):
            offset = idx * ELEMENT_SIZE
            # Only pages being scanned are resident; others can be evicted
            val, = struct.unpack(FORMAT, mv[offset:offset+ELEMENT_SIZE])
            total += val
            # Early exit condition to demonstrate sparse access
            if idx > 5000000 and total > 10000000000:
                break
        print(f"Partial sum: {total}")
        mv.release()

import mmap
import bisect
import struct

# Example 4: Binary search directly on a memory-mapped sorted file
# This algorithm is O(log n) page faults instead of O(log n) read() calls
FILE_PATH = "sorted_ints.bin"
FORMAT = "I"  # unsigned 4-byte int
ELEMENT_SIZE = struct.calcsize(FORMAT)

# Create sorted file: 0, 2, 4, 6, ...
NUM_ELEMENTS = 1_000_000
with open(FILE_PATH, "wb") as f:
    for i in range(NUM_ELEMENTS):
        f.write(struct.pack(FORMAT, i * 2))

def mmap_binary_search(mm, target, num_elements):
    """Binary search over memory-mapped sorted integers."""
    low = 0
    high = num_elements - 1
    
    # Each iteration touches a different page - at most log2(n) faults
    while low <= high:
        mid = (low + high) // 2
        offset = mid * ELEMENT_SIZE
        
        # Direct memory access - no buffer allocation
        mid_val, = struct.unpack(FORMAT, mm[offset:offset+ELEMENT_SIZE])
        
        if mid_val == target:
            return mid  # Found
        elif mid_val < target:
            low = mid + 1
        else:
            high = mid - 1
    return -1  # Not found

with open(FILE_PATH, "rb") as f:
    with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as mm:
        # Search for values - each search faults only ~20 pages for 1M elements
        for target in [0, 123456, 1999998, 1999999]:
            idx = mmap_binary_search(mm, target, NUM_ELEMENTS)
            status = f"found at {idx}" if idx != -1 else "not found"
            print(f"Target {target}: {status}")

        # Bonus: using regex search directly on mapped memory
        # This is extremely fast for log file analysis
        mm.seek(0)
        # Find all occurrences without loading file into Python string
        count = 0
        pos = mm.find(struct.pack(FORMAT, 1000))
        print(f"First occurrence of 1000 at byte offset {pos}")

4. Step-by-Step Example

To make the abstract paging mechanism concrete, consider a practical scenario: we have a 1 GB log file containing fixed-size 256-byte records (approximately 4 million records), and we need to update the status field of record number 2,500,000 and then sequentially scan the next 10,000 records. Let's walk through exactly what happens with a memory-mapped approach versus traditional I/O.

Step 1: Mapping Creation. The application opens the file and calls mmap.mmap(fileno, length=0). The kernel creates a virtual memory area from, say, 0x7f8a10000000 to 0x7f8a50000000 (1 GB). It populates the process's page tables with entries marked as not present, each associated with a file offset. No disk I/O has occurred yet. The resident set size (RSS) of the process has not increased by 1 GB; only virtual address space has been reserved.

Step 2: Random Access Write. The program computes the offset: 2,500,000 * 256 = 640,000,000 bytes. It executes mm[640000000:640000256] = new_record. The CPU attempts to access virtual address 0x7f8a10000000 + 640000000. The MMU finds no valid translation and triggers a page fault. The kernel fault handler allocates a 4KB physical frame, reads the 4KB file block containing that record from disk (aligned to page boundary), copies it into the frame, marks it dirty after the write, and maps it. The write completes at memory speed. Only one 4KB page (containing ~16 records) was loaded, not the entire file.

Step 3: Sequential Scan. The program now loops over the next 10,000 records (about 2.5 MB). For the first page after the written one, another page fault occurs and the kernel, detecting sequential access, begins read-ahead: it may asynchronously fetch the next 8-16 pages (32-64KB) in one disk I/O. As the loop continues, most accesses hit already-resident pages or pages that were prefetched, so the loop runs at near-RAM speed. The kernel's LRU eviction may start discarding earlier pages if memory pressure exists, keeping the working set small.

Step 4: Persistence and Cleanup. The program calls mm.flush() or exits the context manager. The kernel's msync logic walks the page tables for the mapping, finds the dirty page from Step 2, and writes it back to the file's blocks on disk. All other clean pages that were read are simply discarded without I/O. The virtual area is unmapped. If the program had not called flush, the dirty page would still eventually be written by the kernel's background write-back thread within 30 seconds (on typical Linux dirty_writeback_centisecs settings), but durability would not be guaranteed after a crash.

Visualizing Page Faults vs. System Calls

In this example, traditional I/O would have required: one lseek + one write for the random update, plus ~10,000 read calls or a few large buffered reads for the scan, each incurring a context switch and copy. The memory-mapped version incurred ~1 page fault for the write plus ~640 page faults for the scan (2.5 MB / 4KB), but after warm-up, each fault was amortized and subsequent accesses were zero-overhead. For truly random access patterns across the 1 GB file, the difference is even more stark: traditional I/O pays seek+read cost every time, while mmap pays only the fault cost once per page.

5. Complexity Analysis

Analyzing memory-mapped file algorithms requires distinguishing between virtual memory operation cost and the underlying disk I/O cost, because the algorithm's time complexity is dominated by page faults, not by CPU instructions. The Big O notation must account for the fact that the OS pager acts as an implicit cache with its own eviction policy.

For sequential access, memory-mapped files achieve optimal performance. Reading N bytes sequentially incurs O(N / PAGE_SIZE) page faults, each of which may trigger a disk read, but thanks to read-ahead, the effective I/O is O(N / READAHEAD_SIZE) large sequential reads. The amortized time per byte is O(1) after the initial fault, and the CPU cost is simply a memory copy. Space complexity is O(working set) rather than O(N), because only the pages currently touched need to be resident. The kernel can evict pages that have already been scanned, so scanning a 100 GB file on a machine with 8 GB RAM is feasible with constant memory overhead.

For random access, the complexity is more nuanced. Accessing K random positions scattered across the file incurs O(K) page faults in the worst case if each access falls on a different page. If K is large and the access pattern has no locality, this can degenerate into random disk I/O, which is expensive on HDDs but acceptable on SSDs. However, the average case benefits greatly from the page cache: if the working set fits in RAM, subsequent accesses to the same pages are O(1) memory hits with no I/O. This is why memory-mapped structures like B-trees or hash tables with good locality perform exceptionally well.

Write complexity is O(1) per page for the memory operation itself, plus deferred O(1) I/O per dirty page when flushed. The key advantage is write coalescing: multiple writes to the same page before it is flushed result in only one disk write. Traditional write() would issue a system call and potentially a disk write for each update unless the application implements its own buffering.

It is important to note that worst-case time for any operation that triggers a page fault includes disk latency, which can be 5-10ms on HDD or 50-100µs on NVMe SSD. Therefore, while asymptotic complexity remains linear or logarithmic, the constant factor is dominated by storage hardware. Algorithms should be designed to maximize sequentiality and locality to minimize faults.

6. Variations and Optimizations

Not all memory mappings are created equal. The flags and strategies chosen at map time profoundly affect performance and semantics. The most fundamental variation is the choice between MAP_SHARED and MAP_PRIVATE. MAP_SHARED, as used in Python's ACCESS_WRITE, ensures that modifications are visible to other processes and eventually persisted to the underlying file. This is essential for databases and shared caches. MAP_PRIVATE, corresponding to ACCESS_COPY, creates a copy-on-write mapping where writes are private to the process and never reach the file, useful for speculative execution or for safely modifying a file view without affecting the original.

Another critical optimization is the use of huge pages. By default, mappings use 4KB pages, which means a 1 GB mapping requires 262,144 page table entries and TLB entries. On modern CPUs, the TLB has limited capacity (typically 64-1536 entries), so large mappings can cause frequent TLB misses. Using huge pages (2MB or 1GB on x86-64 via MAP_HUGETLB) reduces TLB pressure dramatically and can improve performance by 5-15% for large sequential scans. However, huge pages require special OS configuration and may lead to internal fragmentation.

Prefetching and access hints allow the application to guide the kernel's paging strategy. The madvise() system call (exposed via mmap.madvise() in some Python implementations or via ctypes) lets you declare expected access patterns: MADV_SEQUENTIAL tells the kernel to aggressively read ahead and quickly evict pages after use, ideal for one-pass scans. MADV_RANDOM disables read-ahead, preventing wasteful I/O for random access workloads. MADV_WILLNEED triggers asynchronous prefetch of a range, allowing the application to overlap computation with I/O.

Advanced Techniques

For ultra-large files exceeding virtual address space (on 32-bit systems) or for fine-grained control, sliding window mappings are used. Instead of mapping the entire file, the application maps a fixed-size window (e.g., 256 MB) and remaps it to different file offsets as needed. This technique, sometimes called windowed or chunked mmap, keeps virtual memory usage bounded while still benefiting from paging within each window.

Locking pages with mlock() or MAP_LOCKED pins them in RAM, preventing eviction. This is crucial for latency-sensitive applications like real-time trading systems where a page fault would cause an unacceptable pause. Conversely, for memory-constrained environments, mmap.ACCESS_READ with explicit munmap and remap cycles gives the application manual control over residency, effectively implementing a user-space page replacement policy on top of the kernel's.

Finally, combining memory mapping with non-volatile memory (NVM) and DAX (Direct Access) filesystems eliminates the page cache entirely. On persistent memory hardware, the mapping points directly to the storage media at memory bus speeds, turning msync into a simple cache flush instruction. This blurs the line between memory and storage and enables new algorithms that assume persistence at memory latency.

7. Real-World Applications

Memory-mapped file algorithms are not academic curiosities; they power some of the most performance-critical infrastructure in modern computing. Their ability to handle datasets larger than RAM with near-RAM speed makes them indispensable across domains.

In database systems, memory-mapped files are the foundation of storage engines like LMDB (Lightning Memory-Mapped Database), MongoDB's WiredTiger (in some configurations), and SQLite's memory-mapped I/O mode. LMDB famously uses a single memory-mapped file for its entire dataset and relies entirely on the OS page cache for buffering, which simplifies its code to a few thousand lines while achieving exceptional read concurrency. Readers never block writers because they see a consistent snapshot via copy-on-write pages, and the OS handles all caching and eviction.

Web servers and operating system kernels use memory mapping to serve static files with zero-copy efficiency. The sendfile() system call is often implemented via page cache sharing, but for dynamic content, mapping a file and writing from the mapped region directly to a socket via writev avoids user-space copies. Nginx and Apache use mmap for serving large media files, where the kernel's sendfile and page cache cooperate to stream data without ever copying it into user space.

In data science and machine learning, libraries like NumPy, PyTorch, and TensorFlow use memory-mapped arrays (e.g., numpy.memmap) to work with datasets that exceed RAM. A 50 GB feature matrix can be mapped and accessed as if it were an in-memory ndarray, with only the batches being trained on actually resident. This enables out-of-core learning algorithms on commodity hardware. Similarly, bioinformatics tools map large genome reference files (3 GB for human genome) for fast random access to subsequences without loading the entire sequence.

Perhaps the most ubiquitous use is inter-process communication via shared memory. POSIX shared memory (shm_open + mmap) and Windows file mapping objects allow unrelated processes to share complex data structures by mapping the same file. This is how browsers share rendered bitmaps between processes, how databases share buffer pools, and how high-frequency trading systems disseminate market data with microsecond latency, far faster than pipes or sockets.

8. Comparison with Alternatives

Choosing between memory-mapped I/O and traditional I/O is a critical architectural decision that depends on access pattern, data size, and concurrency requirements. No single approach is universally superior, and understanding the trade-offs is essential for system design.

Standard read/write I/O using read() and write() gives the application explicit control over buffering and I/O scheduling. It is simple, portable, and works well for sequential streaming where the application can manage its own large buffers (e.g., 1 MB). However, it suffers from double copying (disk → page cache → user buffer) and system call overhead per operation. For many small random accesses, this overhead becomes prohibitive.

Buffered I/O via C's fread/fwrite or Python's io.BufferedReader mitigates system call overhead by maintaining a user-space buffer (typically 8KB). This is excellent for sequential text processing but still requires copying and does not help with random access or sharing between processes. The buffer is private to each file descriptor, so two processes reading the same file will each maintain separate copies in RAM.

Direct I/O (O_DIRECT) bypasses the page cache entirely, allowing DMA directly between disk and user buffers. This is useful for databases that implement their own cache (like Oracle) and want to avoid double caching, but it imposes alignment restrictions and shifts the burden of caching and prefetching entirely to the application. It is rarely faster than mmap for general-purpose workloads unless the application has highly specialized knowledge.

Asynchronous I/O (AIO, io_uring) allows overlapping computation with I/O by submitting requests and receiving completions without blocking. While powerful for high-concurrency servers, it adds significant programming complexity and still involves copies and system calls. Memory mapping, by contrast, achieves asynchrony implicitly through page faults and background write-back without any special API.

In practice, the rule of thumb is: use memory mapping for random access, shared data, or files larger than RAM where you want OS-managed caching; use standard or buffered I/O for simple sequential streaming where you need explicit control or portability to systems without mmap; use direct I/O only when building a custom cache that must not interact with the page cache.

9. Common Mistakes and Best Practices

Despite its elegance, memory-mapped I/O is fraught with subtle pitfalls that can lead to data corruption, crashes, or severe performance degradation if not handled correctly. The most common mistake is forgetting that file size and mapping size are decoupled. If you map a file and then extend the file via truncate or write beyond the mapping, accessing the new region results in SIGBUS (bus error) because there is no backing page. Conversely, if another process truncates the file to be smaller than your mapping, any access beyond the new EOF will also SIGBUS. Always ensure the file is sized appropriately before mapping, and handle SIGBUS or use careful length checks.

A second frequent error is ignoring error handling for page faults. Unlike read() which returns -1 on I/O error, a failed page fault due to disk error or network filesystem disconnection delivers a SIGBUS or SIGSEGV signal to the process, which by default terminates it. Robust applications must install signal handlers or use sigsetjmp to recover gracefully, or they must avoid mmap for files on unreliable storage. In Python, this manifests as an opaque OSError or process crash that is hard to debug.

Performance pitfalls are equally common. Mapping many small files (e.g., thousands of 4KB files) is inefficient because each mapping consumes a virtual memory area and page table overhead that dwarfs the data. It is better to consolidate small files or use read() for them. Another mistake is using mmap for purely sequential, one-pass streaming of huge files without advising the kernel. Without MADV_SEQUENTIAL, the kernel may retain pages that will never be reused, polluting the page cache and evicting more useful data. Explicitly calling madvise or periodically calling munmap on consumed windows prevents this.

Best Practices Checklist

• Size before map: Always ftruncate or write to set file size before calling mmap. For new files, write a single byte at the desired length to allocate space.
• Choose access mode deliberately: Use ACCESS_READ for immutable data to allow the kernel to discard pages freely and to get better sharing. Use ACCESS_WRITE only when you need persistence.
• Flush strategically: Do not call flush() after every write; let the kernel batch writes. Call it only at transaction boundaries or before critical durability points. For bulk loads, flush once at the end.
• Handle concurrency: Memory mappings do not provide locking. Use file locks (fcntl.flock) or inter-process mutexes in shared memory to coordinate writers. Remember that writes are not atomic at the page level without synchronization.
• Monitor RSS vs. virtual size: Use tools like pmap, /proc/[pid]/maps, or ps -o rss,vsz to distinguish virtual mapping size from resident pages. A 10 GB mapping with 100 MB RSS is healthy; 10 GB RSS indicates working set thrashing.
• Prefer 64-bit: On 32-bit systems, virtual address space is limited to 2-3 GB, making large mappings impossible. Always use 64-bit Python and OS for memory-mapped algorithms on large files.
• Close correctly: Always close the mmap object before closing the underlying file descriptor, and use context managers to ensure munmap is called even on exceptions.

Finally, be aware of the interaction with fork(). After a fork, the child inherits the mappings. With MAP_SHARED, both processes share the same pages, which is intentional for IPC but can cause subtle race conditions if not expected. With MAP_PRIVATE, the pages become copy-on-write, which can lead to unexpected memory doubling if the child writes to many pages.

10. Interview Questions

Memory-mapped files are a favorite topic in systems and backend interviews because they test understanding of operating systems, virtual memory, and performance trade-offs. Below are common questions and how to approach them.

Q1: Explain what happens step-by-step when you access an unmapped page of a memory-mapped file. What is the role of the page fault handler?
Answer: Describe the creation of the VMA with invalid page table entries, the MMU triggering a page fault on first access, the kernel's fault handler allocating a physical frame, reading the file block via the page cache, updating the page table, and retrying the instruction. Emphasize that this is demand paging and that subsequent accesses are TLB hits with no kernel involvement. Mention read-ahead as an optimization that may have already prefetched the page.

Q2: When would you choose mmap over read/write, and when would you avoid it? Discuss with examples.
Answer: Choose mmap for random access (e.g., binary search in a sorted file, database index lookup), for sharing memory between processes, or for files larger than RAM where you want OS-managed paging (e.g., processing a 100 GB log). Avoid mmap for small files where mapping overhead exceeds benefit, for sequential streaming where simple buffered I/O is sufficient and more portable, for files on unreliable network filesystems where SIGBUS handling is complex, or when you need explicit control over I/O scheduling and error handling per operation. Provide the trade-off table concepts: zero-copy vs. double copy, shared vs. private buffers.

Q3: What is the difference between MAP_SHARED and MAP_PRIVATE? How does copy-on-write work?
Answer: MAP_SHARED means writes are visible to other processes mapping the same file and are eventually written back to the file; the mapping shares the same physical pages in the page cache. MAP_PRIVATE creates a copy-on-write mapping: initially shares pages read-only, but on first write, the kernel copies the page to a new private frame for that process, so modifications are invisible to others and never reach the file. This is used for private, speculative modifications. Mention Python's ACCESS_WRITE vs. ACCESS_COPY.

Q4: You memory-map a 10 GB file on a machine with 4 GB RAM and sequentially scan it. Will the machine run out of memory? What happens to the page cache?
Answer: No, it will not OOM if done correctly. Only the working set (a few MB of recently touched pages) needs to be resident. As the scan progresses, the kernel's LRU eviction will discard clean pages that have already been scanned, since they can be re-read from disk if needed. The virtual size will be 10 GB, but RSS will stay bounded. However, without MADV_SEQUENTIAL, the kernel might keep pages longer than necessary, polluting the cache; advising sequential access helps it evict quickly. Dirty pages would need write-back, but a read-only scan has no dirty pages.

Q5: How do you ensure data written via mmap is durable on disk? What is the difference between msync and fsync?
Answer: Writes to a MAP_SHARED mapping only dirty the page in the page cache; they are not immediately durable. To ensure durability, call msync(MS_SYNC) (Python's mmap.flush()) which blocks until dirty pages in the mapped range are written to disk. fsync() operates on a file descriptor and flushes all dirty pages for that file, including those not necessarily mapped. Both guarantee persistence after return, whereas msync(MS_ASYNC) schedules write-back but returns immediately. Discuss that without msync, data may be lost on crash, and that many databases use msync at transaction commit.