Re: network-namespace-aware nfsd

[Stanislav Kinsbursky <skinsbursky@parallels.com>]

05.10.2011 22:19, J. Bruce Fields пишет:
>
> I don't think so.  Here's roughly how nfsd looks up an inode given a
> filehandle:
>
> 	- look up the ip address in the auth.unix.ip cache (filled by
> 	  rpc.mountd) and get a "struct auth_domain", which represents
> 	  some set of clients.  (E.g., "*.example.com").
> 	- extract the part of the filehandle that represents the export
> 	  and look that up in the nfsd.fh cache (also filled by
> 	  rpc.mountd); result is a path, resolved to a (vfsmount,
> 	  dentry) in the context of rpc.mountd.
> 	- look up the (auth_domain, path) pair in the nfsd.export cache
> 	  (again filled by rpc.mountd) to get export options (ro vs rw,
> 	  security requirements, etc.).
>
> As long as we create per-network-namespace auth.unix.ip, nfsd.fh, and
> nfsd.export caches, and as long as nfsd does those lookups in the right
> cache (which should be easy, as it can always reach the namespace from
> rqstp->rq_xprt->xpt_net).... I think it all works.  Do you see any
> problem?
>

I'm not so familiar with NFS server code. So, probably, you are right and no 
problems here at all.

>
> Similarly net/sunrpc/svc.c:svc_process_common(), where the version check
> is normally done, knows what namespace the request is associated with
> (again by looking at xpt_net), and could look up the supported versions
> per-namespace.
>
> As long as everything on the server side is passed a struct svc_rqst, I
> don't think having distinct thread pools would simplify anything.
>
> Do you think I'm missing anything?
>

I realized, that probably no. At least I can't find any issues for now.

> Also, do you think per-namespace version support is important?
>

Actually, yes, I do.
As I see it, nfsd filesystem have to virtualized to provide flexible control for 
server features. If so, then we need to virtualize program as well.

>
> To start with I suspect it would be OK to share the one lockd thread.
>

Yep, I think so too. It just will be harder to implement.
Anyway, thanks for comment.

> Some day I would very much like to allow lockd to be multithreaded.  But
> I don't know that we'd want separate threads per namespace.
>
> --b.


-- 
Best regards,
Stanislav Kinsbursky