[SCM] Samba Shared Repository - branch v3-0-test updated - release-3-0-32-11-g0b39c04

[simo]

On Thu, 2008-09-04 at 14:34 -0700, Jeremy Allison wrote:
> On Thu, Sep 04, 2008 at 02:24:56PM -0700, James Peach wrote:
> > 2008/9/4 Jeremy Allison <jra at samba.org>:
> > > On Thu, Sep 04, 2008 at 09:37:40AM -0700, Jeremy Allison wrote:
> > >
> > >> I don't think it's a big problem else we'd see many
> > >> more corrupted tdb's than we do, so your thoughts on
> > >> the matter would be most appreciated.
> > >
> > > Having said that, look at this report on Darwin....
> > >
> > > http://lists.apple.com/archives/darwin-development/2003/Mar/msg00034.html
> > >
> > > Probably a bug, but it does seem unclear all round.
> > > We need some test results to benchmark this. I'll
> > > bug Simo to do some (and do some myself :-) :-).
> > 
> > By way of FYI, I have seen 1 customer on Mac OS X with some
> > gencache.tdb corruption (hash chain loop).
> 
> I'm coming to the conclusion (after some research)
> that any system that doesn't implicitly msync(MS_ASYNC)
> on munmap is inherently buggy :-).

Ok, but if non-buggy OSs already do an msync(MS_ASYNC) during munmap()
then adding an explicit msync(MS_ASYNC) would be totally harmless,
wouldn't it ?

So maybe we can just change the added msync() from MS_SYNC to MS_ASYNC
and all systems will be just happy ?
(assuming msync(MS_ASYNC) is not buggy on that system :-)

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <simo at redhat.com>