[PATCH] lib: Fix gencache_del

[Ralph Boehme]

On Mon, Mar 07, 2016 at 08:35:46AM +0100, Volker Lendecke wrote:
> On Mon, Mar 07, 2016 at 08:17:21AM +0100, Ralph Boehme wrote:
> > > Be aware that dbwrap_lmdb is far from finished. It might be
> > > possible to use it when my dbwrap_nolock lands. lmdb does
> > > not not have per-record locking, which we right now need.
> > 
> > Iirc we only need per-record locking when doing a traverse in order to
> > prevent deletion of the record from underneath us in the callback.
> 
> Oh, right. I meant chain-locking. "dbwrap_fetch_locked"
> holds some lock on the database. With tdb it's the chain,
> but that is strictly too coarse. The main point is that we
> do hold some os-level lock while doing open() and unlink()
> for example. I am working to get rid of this. If that's
> gone, we can contain the lmdb-level write transaction in a
> very narrow spot without any blocking operations in between.

sure.

> > > With the current 2-db architecture we can write and get
> > > "eventual consistency" across crashes. I'm not sure lmdb
> > > without sync keeps the stuff that was last sync'ed always
> > > consistent, even under subsequent write traffic.
> > 
> > It's sync by default, so unless you specify MDB_NOSYNC when creating
> > the env the db will always be consistent. We should also pass
> > MDB_WRITEMAP and for things like gencache probably MDB_NOMETASYNC.
> 
> Right. But a sync gencache is waay too slow unless we do
> at least bulk gencache_set operations. It's the idmap cache
> that kills it. Imagine someone with 200+ groups logging in.
> You don't want 200 individual synchronous db operations for
> this.

yeah, that's why I was expecting that gencache should be slower when
doing a single sync cache layer with lmdb. Interestingly I wasn't yet
able to proove that. :)

-Ralph

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de,mailto:kontakt@sernet.de