[PATCH] lib: Fix gencache_del

[Volker Lendecke]

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.

> > 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.

Volker

-- 
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 at sernet.de