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).
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
