A significant downside of using both the blocking [p]read[v](2) / [p]write[v](2) APIs as well as the mmap(2) (actually much more so with the mmap) is this: they depend on the kernel page cache always being populated with the file's pages (that it's working upon or mapping). If this is not the case—which can happen when the data store is much larger than RAM size (that it, files can be enormous)—it will result in a lot of meta-work by the kernel memory management (mm) code to bring in pages from disk to page cache, allocating frames, stitching up page table entries for them, and so on. Thus, the mmap technique works best when the ratio of RAM to storage is as close to 1:1 as possible. When the storage size is much larger than the RAM (often the case with enterprise-scale software such as databases, cloud virtualization at scale, and so on), it can suffer from latencies caused by all the meta work, plus the fact that significant amounts of memory will be used for paging metadata.

Two I/O technologies—DIO and AIO—alleviate these issues (at the cost of complexity); we provide a brief note on them next. (Due to space constraints, we focus on the conceptual side of these topics; learning to use the relevant APIs is then a relatively easy task. Do refer to the Further reading section on the GitHub repository.)