01.03.2012 01:44, bfields@xxxxxxxxxxxx пишет:
On Wed, Feb 29, 2012 at 02:45:12PM -0500, Jeff Layton wrote:
On Wed, 29 Feb 2012 22:39:01 +0400
Stanislav Kinsbursky<skinsbursky@xxxxxxxxxxxxx> wrote:
Hi, Jeff.
I'll try to explain, how all this namespaces-aware SUNRPC PipeFS works.
The main idea is, that today we have 2 types of independently created and
destroyed but linked objects:
1) pipe data itself. This object is created whenever kernel requires (on mount,
module install, whatever)
2) dentry/inode for this pipe. This object is created on PipeFS superblock creation.
This means, any kernel user of SUNRPC pipes have to provide two mechanisms:
1) Safe call (in per-net operations, if the object is global your case) for
PipeFS dentry/inode pair. This is done this in nfsd4_init_cld_pipe().
2) Notifier callback for PipeFS mount/umount operations. Note: this callback is
done from SUNRPC module (i.e. you have to get nfsd module); this callback is
safe - i.e you can be sure, that superblock is valid.
This is the part I'm having a hard time with. IIUC, the existing
examples are fairly clear since you have a 1:1 ratio of objects: a
per-net object (the pipe data) that is hooked up to a dentry/inode in a
per-net sb.
Here though, we don't really have that. We have a global pipe object
and I don't see how you can hook that up to multiple dentries/inodes.
One possibility is to completely "namespacify" this code -- don't use a
global rpc_pipe object and make it per-net instead. If I do that though,
then I suppose I'll also need to make all of the
nfsd4_client_tracking_ops take a struct net arg as well?
That does sound like what we'll want eventually.
And callers will use pass svc_rqst->rq_xprt->xpt_net there, I assume.
(Or actually we may need a pointer to the netns from the nfs4 client?)
Hi, Bruce. I haven't think about the whole structure yet. But I'm going to work
on NFSd containerization soon.
Hope for your assistance.
--
Best regards,
Stanislav Kinsbursky
--
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
