On Wed, 4 Jul 2012, Nico Williams wrote:
Oddly enough the manpages at the Open Group don't make this clear. So
I think it may well be advisable to use msync(3C) before munmap() on
MAP_SHARED mappings. However, I think all implementors should, and
probably all do (Linux even documents that it does) have an implied
msync(2) when doing a munmap(2). I really makes no sense at all to
have munmap(2) not imply msync(3C).
As long as the system has a way to track which dirty pages map to
particular files (Solaris historically does), it should not be
necessary to synchronize the mapping to the underlying store simply
due to munmap. It may be more efficient not do to that. The same
pages may be mapped and unmapped many times by applications. In fact,
several applications may memory map the same file so they access the
same pages and it seems wrong to flush to underlying store simply
because one of the applications no longer references the page.
Since mmap() on zfs breaks the traditional coherent memory/filesystem
that Solaris enjoyed prior to zfs, it may be that some rules should be
different when zfs is involved because of its redundant use of memory
(zfs ARC and VM page).
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
zfs-discuss mailing list