When is mmap preferable to read/write for file I/O?

A strong answer

A strong candidate frames When is mmap preferable to read/write for file I/O? around the exact memory layout, compiler semantics, and hardware execution model covered in Memory-Mapped I/O with mmap and msync. Explain mmap advantages: random access, page-cache sharing, zero-copy, and when it is worse (small files, sequential access).

1. The storage controller transfers data into the kernel page cache via DMA.
2. The CPU traps into the kernel, checks buffer bounds, and executes copy_to_user(), copying the bytes across protection domains into your application's user-space buffer.
3. Every 4 KB read incurs the latency of a system call context switch.

Now consider processing a 10 GB binary database index on a system with only 4 GB of RAM:

• You cannot malloc(10 GB)—the allocation fails or exhausts physical memory.
• Navigating through lseek() and small read() calls requires thousands of context switches.

In a production interview, always connect the specification rule to its concrete runtime consequence: state what lives on the stack versus the heap or static storage segment, how the compiler or operating system validates alignments, lifetimes, and error codes, and what happens under adversarial or boundary inputs (such as zero-length buffers, integer overflow, concurrent mutation, or partial I/O). Backing your explanation with a small trace of register/memory state transitions immediately separates senior systems engineers from candidates who only memorized syntax.

What the interviewer is listening for

• Mastery of core invariant: Map regular files into virtual address space using mmap with MAP_SHARED and MAP_PRIVATE.
• Mastery of core invariant: Trace demand paging and page fault resolution from virtual memory to the kernel page cache.
• Mastery of core invariant: Synchronize dirty memory pages to disk storage deterministically using msync.
• Hardware and ABI awareness: Explaining how sizes, alignments, calling conventions, or kernel boundaries behave on real 64-bit targets rather than relying on implementation-defined assumptions.
• Defensive engineering: Naming the exact compiler flags (-Wall -Wextra -Werror), static analyzers, or runtime sanitizers (-fsanitize=address,undefined,thread) that verify correctness in CI.

Common mistakes

• Explaining only surface syntax without tracing the underlying memory addresses, ownership lifetime, or kernel/user-space state transitions.
• Assuming undefined behavior (such as signed overflow, uninitialized reads, strict-aliasing violations, or dangling pointers) will "just work" because it passed an unoptimized -O0 debug build.
• Ignoring return codes, partial reads/writes, alignment padding, or cleanup paths when an allocation or syscall fails midway through a function.