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

[simo]

On Fri, 2008-09-05 at 10:15 -0700, James Peach wrote:
> 2008/9/4 Jeremy Allison <jra at samba.org>:
> > 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.
> 
> The consensus is that the msync isn't necessary if you are willing to
> live with the data consistency issues (eg. system crash before the
> dirty pages are flushed). Adding the msync will cause disk I/O but
> give you deterministic behaviour WRT when data is flushed.
> 
> IMO msync(MS_ASYNC) is the right thing to do.

Ok I guess that in-memory-only tdbs or the ones that get deleted and
recreated at restart could avoid it then.

But for persistent databases we should do it unless someone go and
convert all the persistent ones to always use transactions.

Simo.

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