Hello, the first paragraph of the msync() man page seems to be inaccurate and leaves room for some ambiguity: > msync() flushes changes made to the in-core copy of a file that was > mapped into memory using mmap(2) back to the filesystem. Without use > of this call, there is no guarantee that changes are written back > before munmap(2) is called. To be more precise, the part of the file > that corresponds to the memory area starting at addr and having > length length is updated. Somebody new to memory mapped files could misinterpret the 2nd sentence as: if I don't call msync() before munmap() then this alone might be enough for changes to get lost (even in the absence of a system crash - e.g. due to a power failure). Which isn't the case. Also, it kind of implies that one didn't need to call msync() last thing before a munmap() because the munmap() would already do the syncing - as if munmap() would guarantee it then. Also not true. See also https://stackoverflow.com/a/13301881/427158 for a post that describes some confusion after comparing the man page with APUE. The msync() man page currently doesn't address any of the following questions especially somebody new to memory mapped files likely has: a) Has p=mmap(0, file_size, ..., fd) followed by some writes through p and then msync(p, file_size, MS_SYNC); the same effect as if the same writes were done with write syscalls through fd followed by an fsync(fd)? Answer: yes b) Is msync() necessary such that another process that has shared-mapped the same file sees the changes? Answer: no, because both processes ultimately access the same physical pages. c) Is msync() necessary such that a read() by another process to the changed file region returns the changed data? Answer: no, because Linux has a unified virtual memory system d) What is the purpose of msync() on Linux? Answer: With MS_SYNC, a successful msync() guarantees that changes are written to disk. e) How does Linux's msync() semantics differ from POSIX? Answer: POSIX doesn't require a unified virtual memory system. AFAICS, thus, on a POSIX conforming system without a unified virtual memory system, a msync() might be required for a read() by another process to return the changed file content. Btw, the 'The Linux Programming Interface' book describes in Chapter 49 that Linux has a unified virtual memory system and that it isn't required by SUSv3 (page 1032), but the sentence > Thus, the views of a file obtained via a mapping and via I/O system > calls (read(), write(), and so on) are always consistent, and the only > use of msync() is to force the contents of a mapped region to be > flushed to disk. seems to conflict with the last sentence of the first paragraph in section 49.5 (page 1031): > Calling msync() also allows an application to ensure that updates to a > writable mapping are visible to some other process that performs a > read() on the file. Best regards Georg
