On Mon, Oct 01, 2012 at 06:05:57PM +0400, Stanislav Kinsbursky wrote: > 01.10.2012 15:51, Jeff Layton пишет: > >- Do we need to switch to a different mount namespace somehow based on > > the net namespace? Eventually we want to allow nfsd to run in a > > container. At some point we'll need a mechanism to ensure that the > > upcall runs within the correct container. Stanislav, I'd appreciate > > your input here... > > Hello, Jeff. > As far as I can see - yes, we have to switch to desired mount > namespace in kernel (because we can't do this in user namespace). > Moreover, for NFSd mount namespace looks even more important than > net namespace. I.e. we can't share one NFSd between mount namespaces > (at least, I don't understand how to do this safely). > So, if we are going to have NFSd per container, we have to tie NFSd > and mount namespace somehow. > Having one NFSd for more than one network namespace looks feasible. > But we have some races with creation and destruction of service > per-net transports, and Bruce was suggesting to think about maybe we > can just simplify all that stuff and create service per network > namespace. > > BTW, is it possible to split service (trasports, etc.) and it's > "executors" (kernel threads)? If we could do it, then it would be > really easy to create as many services (with it's unique namespaces > combination) as required and teach "executors" to switch to desired > namespaces while handling service requests. I'm sure it is possible, and would be more efficient than requiring (number of containers) * (number of threads per container) threads. But I think it's also a little more complicated to do, and that to start off we'd be better off just keeping the services entirely separate. --b. -- 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
