Summary
Memory-mapped files look like an easy way to build a database: map the file, let the operating system page data in and out, and skip writing a buffer pool. Several systems have started this way. The authors argue that this convenience hides serious problems.
They describe four categories of issues. Transactional safety is hard because the OS can flush dirty pages at any time. I/O stalls are unpredictable because page faults block threads. Error handling is awkward because I/O errors arrive as signals. Performance suffers from page table contention, single-threaded eviction and TLB shootdowns. Benchmarks show mmap falling well behind explicit I/O on fast NVMe storage.
The paper is a strong argument for a database managing its own buffer pool and I/O. It connects directly to this community's work on I/O models such as io_uring and on buffer management.