On Fri, 2009-08-21 at 09:42 -0400, Jeff Layton wrote:
> On Wed, 19 Aug 2009 19:38:53 -0400
> Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote:
>
> > The NFSv4 and NFSv4.1 protocols both allow for the redirection of a client
> > from one server to another in order to support filesystem migration and
> > replication. For full protocol support, we need to add the ability to
> > convert a DNS host name into an IP address that we can feed to the RPC
> > client.
> >
> > We'll reuse the sunrpc cache, now that it has been converted to work with
> > rpc_pipefs.
> >
> > Signed-off-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx>
>
>
> I'm happy to see this problem get resolved. Much of this functionality
> however is already provided by the keys API. While it's more geared
> toward dealing with auth tokens, it's still a fairly decent generic upcall
> implementation and could easily have been used here with a lot less new
> code added. Why did you decide to roll your own implementation instead?
As I told you at Connectathon, I don't trust the keyring mechanism at
all for this.
The user is free to inject anything they want into their keyring caches.
Trusting that information when doing a mount onto a shared namespace is
inappropriate.
The point then is that if you can't trust the caching mechanism, then
you have to build a new cache. I chose to reuse Neil's rpc-cache stuff,
because it has some nice properties:
* Write access is restricted to privileged processes using
standard filesystem techniques.
* The cache contents can be easily verified using the 'contents'
pseudofile.
* The contents can be easily cleared using the 'flush' pseudofile.
The only property I really didn't like about his cache mechanism (that
it uses procfs), I easily worked around.
As I said to Chuck, the plan is to also rewrite the idmapper to use a
similar mechanism. The current idmapper has scalability problems that we
need to address in order to make NFSv4 perform in environments with lots
of users.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
