Russ Allbery wrote: > "Zack Weinberg" <zack@xxxxxxxxxxxx> writes: > >> For Autoconf's purposes, what we really need to know is: on OpenBSD, >> what does an application need to do after it modifies a MAP_SHARED >> mapping using memory writes to make those writes visible to read()? I don't believe there is a valid answer to that question. In LMDB's case we just say "don't do that". > Many years ago when I did work on this for INN to make heavier use of mmap > for its new (at the time) overview system, calling msync() after changes > to a MAP_SHARED mapping would cause the writes to be visible to read() on > some platforms, and likewise to make write() modifications visible in the > shared map. This was more than 20 years ago, though, and while INN still > has all of that portability code, we haven't systematically tested it in > quite a while. The documentation for msync only says that it will flush out changes made to a writable mmap region out to the filesystem. I guess that means that they should then be visible to filesystem-oriented APIs like read() but that isn't explicitly stated. Also, since it only talks about changes made to mappings, it doesn't imply anything at all about changes made via write() or whether they become visible in a mapping. I think the fact that this worked for INN was probably mostly luck. > The other problem we encountered at the time was with NFS. Even on > platforms where normally changes to a MAP_SHARED mapping were immediately > visible to read() and changes with write() were immediately visible to the > mapping, this often would break if the underlying file system were a > remote NFS mount. > > In that case, an explicit msync() helped with writes. Reads were, as I > recall, a more complicated problem since it wasn't obvious when to call > msync(). INN has code to call fstat() on the file descriptor underlying > the MAP_SHARED mapping because the symptom we saw at the time is that this > would return ESTALE if there had been a write (which INN then uses as a > trigger to unmap and remap the file). > > Here too I have not revalidated this subsequently. This would have been > in the days of NFSv3 (if not NFSv2 in places). NFS and its interaction with caching layers is still a mystery. This is another thing that we just say "don't do that" with LMDB. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
