On Thu, 29 Nov 2012 15:53:47 +0400 Stanislav Kinsbursky <skinsbursky@xxxxxxxxxxxxx> wrote: > 29.11.2012 00:28, Jeff Layton пишет: > > On Wed, 28 Nov 2012 15:01:26 -0500 > > "bfields@xxxxxxxxxxxx" <bfields@xxxxxxxxxxxx> wrote: > > > >>> 3) Holding net by tracker looks redundant. What was the reason for this? > >> > >> I don't understand, what's tracker? > > > > I assume he means the clientid tracker. That was necessary for the > > nfsdcld upcall because it used rpc_pipefs files, and those were > > net-namespacified. Once we deprecate that in 3.10, I don't think we'll > > need to worry about the net namespace in the clientid tracker. > > > > Sorry, I don't understand. Rpc_pipefs superblock already holds network namespace. > ...and how do you know which rpc_pipefs superblock you're dealing with? In any case, I'm ok with ripping out references to the net namespace there if you think it's valid. > > We probably *will* need to concern ourselves with the mnt namespace > > there though since each container will presumably have its own clientid > > database... > > Since NFSd server in network namespace based, it means, that we can create one server for more than one mount namespace. > And clietid tracker holds files opened. Thus holds mount. > Mount namespace itself doesn't look that important to me. > Or I'm wrong? > I confess I don't understand the design well enough to reasonably comment here... Both the new clientid tracker and the legacy one involve storing data on a local filesystem somewhere. In the case of the new tracker, we upcall using call_usermodehelper to spawn a process to handle access to the on disk database. In the legacy tracker, it's done directly by the kernel using vfs calls. Presumably, you will have multiple containers serving NFS, so you'll have multiple sets of client id data being stored. You'll need some mechanism to ensure that the usermodehelper is spawned within the correct container or that the legacy tracker accesses the files in the correct container. My assumption there was that you'd need to ensure that it's using the right mount namespace in order to do that... -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
