Re: [SCM] Samba Shared Repository - branch v3-0-test updated - release-3-0-32-11-g0b39c04
Hi Simo, > The msync manpage reports that msync *must* be called before > munmap. Failure to do so may result in lost data. Fix an ifdef > check, I really think we meant to check HAVE_MMAP here. Please revert this change immediately. That change would slow down tdb by a couple of orders or magnitude for our temporary databases. The msync map page if referring to losing data if the machine crashes before the data is flushed. If we want safety against that we should use tdb transactions, which do all the right calls (and no, just doing a msync like that is NOT enough). and please check with somebody who knows systems programming before making a change like this. Cheers, Tridge
Re: [SCM] Samba Shared Repository - branch v3-0-test updated - release-3-0-32-11-g0b39c04
Hi Simo, > Please revert this change immediately. That change would slow down tdb > by a couple of orders or magnitude for our temporary databases. actually this will only slow us down each time we attach/detach to the tdb or we expand it (as expand uses munmap/mmap). I guess the question is how often we expand our temporary tdb's. A simple change would be for this not to apply if TDB_CLEAR_IF_FIRST is set. Cheers, Tridge
Re: [SCM] Samba Shared Repository - branch v3-0-test updated - release-3-0-32-11-g0b39c04
Hi Simo, > and please check with somebody who knows systems programming before > making a change like this. also, my apologies for this. Kai and Andrew have now pointed me at the thread where you asked about this, and got an ack from Jeremy. It seems I'm not getting samba-technical email at the moment. I'm trying to find out why. Cheers, Tridge
Re: [SCM] Samba Shared Repository - branch v3-0-test updated - release-3-0-32-11-g0b39c04
On Thu, Sep 04, 2008 at 03:48:11PM +1000, [EMAIL PROTECTED] wrote: > Hi Simo, > > > Please revert this change immediately. That change would slow down tdb > > by a couple of orders or magnitude for our temporary databases. > > actually this will only slow us down each time we attach/detach to the > tdb or we expand it (as expand uses munmap/mmap). I guess the question > is how often we expand our temporary tdb's. > > A simple change would be for this not to apply if TDB_CLEAR_IF_FIRST > is set. What about changing the MS_SYNC flag in the msync call to MS_ASYNC instead ? That would seem to have the desired effect in that it satifies the (seeming) requirement that msync be called before munmap, but won't block until all writes are finished. Jeremy.
Re: [SCM] Samba Shared Repository - branch v3-0-test updated - release-3-0-32-11-g0b39c04
On Thu, Sep 04, 2008 at 09:56:31AM -0700, Jeremy Allison wrote: > On Thu, Sep 04, 2008 at 03:48:11PM +1000, [EMAIL PROTECTED] wrote: > > Hi Simo, > > > > > Please revert this change immediately. That change would slow down tdb > > > by a couple of orders or magnitude for our temporary databases. > > > > actually this will only slow us down each time we attach/detach to the > > tdb or we expand it (as expand uses munmap/mmap). I guess the question > > is how often we expand our temporary tdb's. > > > > A simple change would be for this not to apply if TDB_CLEAR_IF_FIRST > > is set. > > What about changing the MS_SYNC flag in the msync call to MS_ASYNC > instead ? That would seem to have the desired effect in that it > satifies the (seeming) requirement that msync be called before > munmap, but won't block until all writes are finished. Hmmm. Nope. Checked the Linux source code and msync(MS_ASYNC) is a no-op :-). Jeremy.
