Subject: [nfsv4] [FedFS] caching LDAP lookups

From: Paul Lemahieu <[email-masked]>
Date: Fri, 29 May 2009 15:27:09 -0700

I spoke briefly with Mario today about the LDAP caching issue, and he  
echoed our comments about how LDAP directories already see peak load  
situations first thing in the morning, etc, and he would expect the  
LDAP infrastructure to handle FedFS lookups.

That said, he also pointed out that many NFSv4 server vendors  
implement a cache for uid/gid lookups, since NFSv4 requires the return  
of user and group names, not ids, and many implementations do and LDAP  
lookup to resolve the internally stored uid/gid to the real name. LDAP  
lookups were found to be a performance issue.

The NFSv4 standard makes no mention or recommendations on server  
caching of these values. It is not an analogous situation, however,  
since NFSv4 makes no assumptions about how the server is storing user  
and group information, so has no idea if servers are even doing any  
LDAP queries.

Mario felt caching was a good idea, and that some basic  
recommendations and defaults should be made in the FedFS standard to  
guide those who wish to cache LDAP lookups.

--Paul

---

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 30 May 2009 14:37:05 -0400

The NFSv4 standard makes no mention or recommendations on server
caching of these values. It is not an analogous situation, however,
since NFSv4 makes no assumptions about how the server is storing user
and group information, so has no idea if servers are even doing any LDAP
queries.

If the file system is not prepared to store the user and group names
(and I don't know of any file systems which are), then it typically
interrogates a mapping (store in LDAP for example) and then stores the
32-bit id it gets in the file system file attributes.  The point here is
that, even if you are not caching the values specifically, you (by
storing the id's in the file system) are depending on the mapping not
changing.  So given that you are depending on them not changing anyway,
adding caching to the mapping interrogation infrastructure doen't add
any knew issues.  You still can't can't really change the mapping and
return the same user and group values that were stored to the clients
that interrogate them.

________________________________

From: Paul Lemahieu [mailto:[email-masked]] 
Sent: Friday, May 29, 2009 6:27 PM
To: [email-masked]
Subject: [nfsv4] [FedFS] caching LDAP lookups

I spoke briefly with Mario today about the LDAP caching issue, and he
echoed our comments about how LDAP directories already see peak load
situations first thing in the morning, etc, and he would expect the LDAP
infrastructure to handle FedFS lookups. 

That said, he also pointed out that many NFSv4 server vendors implement
a cache for uid/gid lookups, since NFSv4 requires the return of user and
group names, not ids, and many implementations do and LDAP lookup to
resolve the internally stored uid/gid to the real name. LDAP lookups
were found to be a performance issue.

The NFSv4 standard makes no mention or recommendations on server caching
of these values. It is not an analogous situation, however, since NFSv4
makes no assumptions about how the server is storing user and group
information, so has no idea if servers are even doing any LDAP queries.

Mario felt caching was a good idea, and that some basic recommendations
and defaults should be made in the FedFS standard to guide those who
wish to cache LDAP lookups.

--Paul