Quoting J. Bruce Fields (bfields@xxxxxxxxxxxx): > 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
