On Thu, 2008-06-19 at 13:27 -0400, Jeff Layton wrote:
> There's also no reason we couldn't use keys for
> idmap upcalls as well. I'm considering them for a similar idmap scheme
> for CIFS.
Ewww.... NACK, NACK, NACK, NACK....
There is a perfectly good reason why you wouldn't ever want to use keys
for idmap upcalls: keys are user/process/thread objects while idmapd
entries are NFSv4-namespace objects.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
[email protected]
http://www.netapp.com
On Thu, 19 Jun 2008 14:13:19 -0400
Trond Myklebust <[email protected]> wrote:
> On Thu, 2008-06-19 at 13:27 -0400, Jeff Layton wrote:
> > There's also no reason we couldn't use keys for
> > idmap upcalls as well. I'm considering them for a similar idmap scheme
> > for CIFS.
>
> Ewww.... NACK, NACK, NACK, NACK....
>
> There is a perfectly good reason why you wouldn't ever want to use keys
> for idmap upcalls: keys are user/process/thread objects while idmapd
> entries are NFSv4-namespace objects.
>
My thinking for CIFS is to use keys to do the upcall and copy the
mapping into a cache that we'll manage independently of the key cache.
The CIFS case is a little different though. We're not mapping usernames
to uid's and vice-versa, but Windows RID's to unix uid's. Still, it's a
somewhat similar problem. The amount of data that we're dealing with in
an idmap upcall is pretty small, so copying it and then destroying the
key wouldn't involve a lot of overhead.
That may not be palatable for NFS though.
--
Jeff Layton <[email protected]>