access idmap cache directly from smbd

[Jeremy Allison]

On Mon, Aug 18, 2008 at 11:54:55PM +0200, Michael Adam wrote:
> 
> I agree with Simo in that it feels wrong to have smbd
> write to the idmap cache. I don't understand why smbd
> should. Probably I am just missing somthing here.
> But to my understanding, the idmap cache is somthing
> that winbind should fill and samba should (possibly)
> be able read.
> 
> Your patch replaces the smbd's access to its own idmap-memcache 
> which of course includes store ops with access to the idmap
> cache in gencache.tdb which (i think) smbd should only read.
> 
> > It will speed up Samba operation, because it gets rid of a
> > considerable amount of roundtrips to winbind, in particular
> > together with the third patch that increases the default
> > positive cache timeout to a week.
> 
> What is the real performance problem?
> The roundtrips to winbind or winbind going further to the
> backends?
> The second problem would be solved by simply increasing the
> positive cache time since winbind looks into the idmap cache
> before asking the backends anyways.
> And wouldn't the first be equally well solved by a read-only
> access to the cache by smbd?

Well smbd currently has to cache the lookups from
winbindd in memory, as we don't want it roundtripping
to winbindd on every lookup.

Volker's patch moves that cache into a shared one
with winbindd.

The only complaint that makes sense to me is that
if winbindd isn't running or the lookup fails for
some reason smbd has to call the legacy_convert_XX_to_YY
functions and do the conversion itself.

Currently smbd caches these in memory for reasons
mentioned above, Volker's patch also puts them into
the tdb cache (from my reading of it, corrections
welcome). We might keep a memory cache for those
conversions so we don't write into the winbindd
cache if winbindd isn't running.

But if we're returning these mappings to the
client anyway we've already committed to them,
so what harm storing them in the cache ?

Jeremy.