[RFC][WIP] cache-only name lookups in smbd

Volker Lendecke vl at samba.org
Mon Nov 28 11:06:18 UTC 2016

On Mon, Nov 28, 2016 at 12:59:05PM +0200, Uri Simchoni wrote:
> On 11/28/2016 11:26 AM, Volker Lendecke wrote:
> > Hi, Uri!
> > 
> > Question -- the cache invalidation of winbindd_cache.tdb is fishy at
> > best. For this type of caching that is pretty much public information,
> > wouldn't it be better to go to gencache.tdb? In the caching case, we
> > would avoid the roundtrip to winbind.
> > 
> > Volker
> > 
> You mean introduce another cache or leverage an existing one? There are
> already two of them at least - the winbindd_cache (used to be "backend")
> and the RPC parent-child cache - I can save the round-trip to the child
> by using that.

Both are using the same infrastructure, so for me that is the same
cache. Yes, we cache things more than once, and this is one of the
cleanup todos. The main thing here is that winbindd_cache.tdb is only
accessed from within winbind itself, so every access requires a
process context switch into winbind.

What I have in mind is a structure like our idmap cache: We store the
id mappings with gencache_set and retrieve them with gencache_parse.
The main advantage is that smbd can access them without asking
winbind, so gencache is a *little* more of a stable "API". We could
make winbind store the name2sid and sid2name mappings with
gencache_set and smbd could retrieve them directly.

With idmappings our approach is that they are extremely durable: Once
a sid2unixid is set, it will not change. Period. With name2sid it
might be a bit more prone to change, so we might want to think about
cache expiration based on a bit more than just the gencache timeout.
But as this is very fishy with winbindd_cache.tdb anyway, we have to
put some thought into that topic regardless of the winbindd_cache.tdb
vs gencache.tdb decision.

Hope that helps,


More information about the samba-technical mailing list