Hello Michael,
when analyzing how the fanotify API interacts with mmap(2) I stumbled
over the following issues in the manpages:
The manpage of msync(2) says:
"msync() flushes changes made to the in-core copy of a file that was
mapped into memory using mmap(2) back to disk."
"back to disk" implies that the file system is forced to actually write
to the hard disk, somewhat equivalent to invoking sync(1). Is that
guaranteed for all file systems?
Not all file systems are necessarily disk based (e.g. davfs, tmpfs).
So shouldn't we write:
"... back to the file system."
http://pubs.opengroup.org/onlinepubs/007904875/functions/msync.html
says
"... to permanent storage locations, if any,"
The manpage of munmap(2) leaves it unclear, if copying back to the
filesystem is synchronous or asynchronous.
This bit of information is important, because, if munmap is
asynchronous, applications might want to call msync(,,MS_SYNC), before
calling munmap. If munmap is synchronous it might block until the file
system responds (think of waiting for a tape to be loaded, or a webdav
server to respond).
What happens to an unfinished prior asynchronous update by
mmap(,,MS_ASYNC) when munmap is called?
Will munmap "invalidate other mappings of the same file (so that they
can be updated with the fresh values just written)" like
msync(,,MS_INVALIDATE) does?
Best regards
Heinrich Schuchardt
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
