On Wed, Jul 4, 2012 at 11:14 AM, Bob Friesenhahn
> On Tue, 3 Jul 2012, James Litchfield wrote:
>> Agreed - msync/munmap is the only guarantee.
> I don't see that the munmap definition assures that anything is written to
> "disk". The system is free to buffer the data in RAM as long as it likes
> without writing anything at all.
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).
(That's another thing, I don't see where the standard requires that
munmap(2) be synchronous. I think it'd be nice to have an mmap(2)
option for requesting whether munmap(2) of the same mapping be
synchronous or asynchronous. Async munmap(2) -> no need to mount
cross-calls, instead allowing to mapping to be torn down over time.
Doing a synchronous msync(3C), then a munmap(2) is a recipe for going
real slow, but if munmap(2) does not portably guarantee an implied
msync(3C), then would it be safe to do an async msync(2) then
zfs-discuss mailing list