On Wed, Jul 4, 2012 at 11:14 AM, Bob Friesenhahn
<bfrie...@simple.dallas.tx.us> wrote:
> 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

Reply via email to