On 11/21/2012 02:31 PM, Simo Sorce wrote:
On Tue, 2012-11-20 at 14:29 +0100, Michal Židek wrote:
On 11/20/2012 02:22 PM, Michal Židek wrote:
Patch 1: sss_cache refactor. See patch description for more details.
Patch 2: Remove mmap cache properly in sss_userdel and sss_groupdel
It looks a bit excessive to remove the whole cache when you change 1
user, would be probably better to fix this by a slightly more complex
construct.
After you delete the data from the ldb cache you could query sssd_nss
for the user name. And make sure that sssd_nss also searches the mc
cache and remove the entry if it is found there on user lookup failure
(we can later on use this feature to implement negative caching at the
mc layer).
Simo.
Hmm... we would still need to handle the situation when sssd_nss is not
running. I guess removing the entire mmap cache here is just fine.
But, to the case when sssd_nss is running. Does sss_nss_make_request()
only ldb requests? Or first mc then ldb? I am looking at the client code
now and it looks like this function is called when mc lookup did not
succeeded... so my guess is, that it only requests for ldb data. If so,
then this would be the function to use here.
It would be like:
... in the tool's code ...
sss_nss_make_request(SSS_NSS_GETPWNAM, ...);
... somewhere inside sssd_nss code ...
if (no_results_in_ldb) {
invalidate rec in mc
}
Since the invalidation takes place inside sssd_nss process, no new
synchronization between processes should be needed (the barriers are
already there). But this would only work if sss_nss_make_request
communicates with ldb only (which I think it does).
Was this your suggestion?
Thanks
Michal
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
