Memory-mapped file synchronization (source code)

= Memory-mapped file synchronization

There are two distinct questions: whether another <operating-system process> can observe shared contents, and whether those contents survive a crash. In the timeline, persistent storage deliberately remains $(7,8)$ while the shared <page cache> contains $(11,12)$. No background <page writeback> occurs in this toy interval. Real <page writeback> may persist some contents earlier; shared visibility alone cannot tell the reader which contents are durable.

For the covered shared range, `msync(base, length, MS_SYNC)` requests <page writeback> and waits for completion; check its return value. `MS_ASYNC` is not a durable completion acknowledgment, and on modern <Linux kernel> versions it is a no-op because dirty contents are already tracked. The address must be aligned, so synchronizing our changed second page uses `base + 4096`, length 4096, rather than `base + 4133`. Unmapping alone is not a guarantee of completed writeback.<msync(2) — Linux manual page by Linux man-pages project>[DESCRIPTION, RETURN VALUE, ERRORS and VERSIONS: covered range, MS_SYNC versus MS_ASYNC, page-aligned address, and Linux MS_ASYNC behavior since 2.6.19]{ref}

For persistence of the <file> and associated <file metadata>, <fsync> on an open <file descriptor> is a broader interface; a new <directory entry> needs separate synchronization of its <file-system directory>. Retain a suitable <file descriptor> if the persistence protocol needs it after mapping. Successful storage completion still relies on the <file system> and device honoring their persistence contracts.<fsync(2) — Linux manual page by Linux man-pages project>[DESCRIPTION, RETURN VALUE and ERRORS: file data and metadata, directory entry, completion and reported failures]{ref}

Neither <fsync> nor <msync> supplies <mutual exclusion>, an <atomic storage write> for several <memory pages>, or an application-wide <file-system transaction>. Stop or coordinate writers before deciding which update a completion acknowledges. A crash during <page writeback> can leave a mixture of old and new contents unless a separate recovery protocol provides <file-system crash consistency>. The last timeline row assumes successful synchronous completion, honored <storage flush> semantics and no subsequent writer; it illustrates a persistence boundary, not a promise about arbitrary hardware failures.