On Tue, 2009-01-06 at 14:02 -0600, Serge E. Hallyn wrote: > Quoting Matt Helsley (matthltc@xxxxxxxxxx): > > We can often specify the UTS namespace to use when starting an RPC client. > > However sometimes no UTS namespace is available (specifically during system > > shutdown as the last NFS mount in a container is unmounted) so fall > > back to the initial UTS namespace. > > So what happens if we take this patch and do nothing else? > > The only potential problem situation will be rpc requests > made on behalf of a container in which the last task has > exited, right? So let's say a container did an nfs mount > and then exits, causing an nfs umount request. > > That umount request will now be sent with the wrong nodename. > Does that actually cause problems, will the server use the > nodename to try and determine the client sending the request? The NFSv2/v3 umount rpc call will be sent by the 'umount' program from userspace, not the kernel. The problem here is that because lazy mounts exist, the lifetime of the RPC client may be longer than that of the container. In addition, it may be shared among more than 1 container, because superblocks can be shared. One thing you need to be aware of here is that inode dirty data writebacks may be initiated by completely different processes than the one that dirtied the inode. IOW: Aside from being extremely ugly, approaches like [PATCH 4/4] which rely on being able to determine the container-specific node name at RPC generation time are therefore going to return incorrect values. Trond -- 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
