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

[Jeremy Allison]

On Thu, Sep 04, 2008 at 06:05:59PM -0400, simo wrote:
> 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 :-)

Yeah maybe, but it just feels wrong :-).

I think we should remove it.. I'll wait for a response
from Apple first, but I think it should go.

Jeremy.