A memory-mapped file associates file contents with a virtual-address range, allowing memory access while retaining explicit sharing, writeback, and synchronization rules.
Linux mmap can associate a region of a file, beginning at an offset, with a process address range and selected protections. The program then accesses contents through those addresses rather than issuing read for every access.
Paging and permissions still apply. Establishing a mapping does not imply that every page is already resident. Closing the original file descriptor after successful mmap does not itself invalidate the mapping.
MAP_SHARED exposes updates to other processes mapping the region and carries them to the underlying file under its writeback rules. MAP_PRIVATE instead provides private copy-on-write changes that are not propagated as writes to that file.
Visibility does not establish a correct concurrent protocol. Participants still need synchronization for application invariants. Mapping shared contents does not turn arbitrary sequences of memory writes into database transactions.
Linux msync requests synchronization of mapped changes to the file; MS_SYNC waits for the requested update, while asynchronous semantics differ. Updating memory, visibility to peers, and persistence are separate questions.
Accessing a mapped page beyond the file end can produce SIGBUS. File size, mapping limits, and concurrent changes require care. Mapping supplies an access mechanism rather than eliminating storage errors, bounds, or recovery requirements.