access idmap cache directly from smbd

[simo]

On Mon, 2008-08-18 at 14:14 -0700, Jeremy Allison wrote:
> On Mon, Aug 18, 2008 at 10:28:55PM +0200, Volker Lendecke wrote:
> > On Mon, Aug 18, 2008 at 01:54:35PM -0500, Gerald (Jerry) Carter wrote:
> > > Seems I'm late to the party but isn't this just making the
> > > in memory sid2uid cache that smbd already has use a tdb?
> 
> Looks that way to me. But that's not a bad thing (IMHO).
> 
> > > I agree that a read-only direct to tdb mechanism for smbd
> > > to get idmap information would probably improve performance.
> > > But if it is not optional as Simo suggested, then we've
> > > recoupled smbd and winbindd again.
> > > 
> > > I think for what is needed here, you're idea of a cache
> > > for pdb_ldap (or probably just the sid/id cache in smbd in
> > > general) might be the best bet.
> > > 
> > > Hope these comments may help a little.
> > 
> > As I said: Caching that in pdb_ldap.c does not work, and I
> > don't really like having multiple caches of the same
> > information.
> > 
> > Why don't we see the idmap cache as a subsystem *used* by
> > both winbind and smbd, like tdb for example. It's not that
> > we store any complex data in there that is about to change
> > any time soon.
> 
> I'm happy with this change. It fixes a real customer problem
> and gives a measurable performance improvement.
> 
> The cache info isn't complex enough that it needs to be
> owned by one particular component.

Except when smbd and winbindd get different ideas on what maps to what.
If we can avoid that, then yes I agree, but if smbd and winbindd end up
with different ideas that's a problem.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <simo at redhat.com>