Re: munmap, msync: synchronization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Kerrisk (man-pages) wrote:
> >> 7. On Linux (and probably many other modern systems), the only
> >>    call that has any real use is msync(MS_SYNC), meaning
> >>    "flush the buffers *now*, and I want to wait for that to 
> >>    complete, so that I can then continue safe in the knowledge
> >>    that my data has landed on a device". That's useful if we
> >>    want insurance for our data in the event of a system crash.
> > 
> > Right.  It's basically another way to call fsync, which is used to
> > implement it underneath.  It actually should be a ranged-fdatasync
> > but right it's it's implemented horribly inefficiently in that it
> > does a fsync call for each vma that it encounters in the range
> > specified.

A ranged-fdatasync, for databases with little logs inside the big data
file, would be nice.  AIX, NetBSD and FreeBSD all have one :) Any
likelihood of that ever appearing in Linux?  sync_file_range() comes
with its Warning in the man page which basically means "don't trust me
unless you know the filesystem exactly".

> Thanks for checking all of this over and thanks also
> for confirming that I learned my lessens well in the
> "Jamie Lokier school of tough technical reviewing" ;-).

Hi! That was a long time ago :)

> >> 9. The mmap() man page says this:
> >>
> >>        MAP_SHARED 
> >>            Share this mapping.  Updates to the mapping are vis???
> >>            ible to other processes that map this file, and  are
> >>            carried  through  to  the underlying file.  The file
> >>            may not actually be updated until msync(2)  or  mun???
> >>            map() is called.
> >>
> >>    I believe the piece "or munmap()" is misleading. It implies
> >>    that munmap() must trigger a sync action. I don't think this
> >>    is true. All that it is required to do is remove some range
> >>    of pages from the process's virtual address space. I'm
> >>    inclined to remove those words, but I'd like to see if any
> >>    FS person has a correction to my understanding first.
> > 
> > I would expect non-coherent systems to update their caches on munmap,
> > Posix does not seem to require this, and I can't find any language
> > towards that in the HP-UX man page, which was a system that I remember
> > as non-coherent until the end.
> 
> Yes, that's how I read it too. POSIX seems to have no requirements here,
> so I assume it was catering to to the lowest common denominator.

According to this:

    http://h30499.www3.hp.com/t5/System-Administration/2-second-delays-in-fsync-msync-munmap/td-p/3092785/page/2#.U1WBw8dSI1-

and the conclusion of the following page:

   - munmap() does _something_ on HP-UX, but it might be just a poorly
     implemented artifact rather than equivalent to msync.

   - While we're there, the lowest common denominator for HP-UX was
     that pwrite() followed by mmap() does not provide the data
     recently written, even with fsync() between.  The thread ended
     there, but I would guess either it's a bug _or_ perhaps
     write+mmap+msync(MS_INVALIDATE) are needed in that order despite
     the write being before the mmap, perhaps if the shared segment
     was maintained by another process.

   - To keep it exciting, if you look at the HP-UX man page, 32-bit
     and 64-bit processes have separate mmap caches - writing to
     shared memory in one of them won't be seen immediately by the other.

Then there's this, about Linux NFS incoherency with msync() and O_DIRECT:

    - https://groups.google.com/d/msg/comp.os.linux.development.apps/B49Rej6KV24/xEouZOVXs9gJ

I don't know if any of the above are _true_ though :)

Best,
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux