Re: nfsd and containers

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting J. Bruce Fields (bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org):
> Does anyone have any ideas about how the kernel's nfsd should interact
> (if at all) with network namespaces?
> 
> I'm initially interested because I've been experimenting with modifying
> the server to allow it to present different exported filesystems
> depending on which ip address it's accessed through.  One way to do that
> might be by modifying the kernel to behave as though there's a separate
> nfsd service per network namespace; then we'd need little or no
> modification of the userspace support daemons (statd, the portmapper,
> etc.)--just start multiple instances of them in separate network
> namespaces and teach the kernel to route requests to them to the
> corresponding loopback interface.  (That would work at least for daemons
> that communicate with the kernel exclusively using rpc over loopback.
> We could perhaps do something similar with the various /proc and nfsctl
> interfaces.)
> 
> I'm also curious more generally whether anyone's thought about how nfsd 
> should behave in the presence of containers.

I suspect Eric has had more detailed thoughts than I so I'm waiting
to see his response.  Matt sent a patchset to deal with sunrpc/nfs/uts
namespaces which I haven't yet had a chance to look at, so he might
also have some good comments at this point.

> (Also, I take it the sysfs problem described in
> http://lwn.net/Articles/295587/ is still unsolved?)

Sysfs tagging is not yet implemented, but 2.6.29 is supposed to
have the netdev hack-fix which simply doesn't show /sys/class/net
entries for tasks which are not in the initial network namespace.
That allows network namespaces to be used.

Checking gitweb real quick, yes, CONFIG_NET_NS is an option in
Linus' current git tree.

-serge