[PATCHES] Convert gencache to dbwrap to enable mutexes
cs at samba.org
Tue Jul 8 16:14:49 MDT 2014
On Wed, Jun 25, 2014 at 02:25:46PM +0200, Michael Adam wrote:
> On 2014-06-25 at 14:19 +0200, Volker Lendecke wrote:
> > On Wed, Jun 25, 2014 at 02:05:08PM +0200, Michael Adam wrote:
> > > On 2014-06-25 at 13:35 +0200, Volker Lendecke wrote:
> > > > On Wed, Jun 25, 2014 at 01:18:27PM +0200, Michael Adam wrote:
> > > > > This would allow to use mutexes correctly
> > > > > on gencache_notrans. In order to convert
> > > > > it to dbwrap, we need to add a means of
> > > > > using allrecord lock via dbrwap (it does
> > > > > currently not offer it).
> > > >
> > > > ... and I would try to avoid this. I'm not sure I want to
> > > > think about implementing an allrecord lock for a ctdb
> > > > database. I'd rather not go through dbwrap for
> > > > gencache_notrans if that's the only reason to implement a
> > > > dbwrap_allrecord_lock.
> > >
> > > Right, but we could of course choose to *not* implement it
> > > in the dbwrap_ctdb case...
> > >
> > > Independently of the choice whether to do the allrecord
> > > lock throught ctdb or not, do you think the above change
> > > to gencache_stabilize (on the tdb level) would make sense?
> > Sure. But with your freelist patches, do we still need the
> > wipe_all? This should be a nice test if freelist compaction
> > actually works as designed :-)
> Ok, sure!
> But in that case I would do rather a second traverse of the
> cache_notrans db and do tdb_delete there, in order not to
> loose entries if the transaction on the persistent db fails.
> Not as performant as using wipe_all probably, but still. :-)
Sorry, i got a bit lost in this discussion. Is the current proposal
changing gencache_notrans to not use transactions, convert it to dbwrap
and add the mutex check to the local dbwrap codepath?
I can take a stab at implementing that.
More information about the samba-technical