-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for the bad quoting below:
[EMAIL PROTECTED] wrote: > On Fri, 28 Jan 2005, Mike Waychison wrote: > > Al Viro wrote: > >>>> OK, here comes the first draft of proposed semantics for subtree >>>> sharing. What we want is being able to propagate events between >>>> the parts of mount trees. Below is a description of what I think >>>> might be a workable semantics; it does *NOT* describe the data >>>> structures I would consider final and there are considerable >>>> areas where we still need to figure out the right behaviour. >>>> > > Okay, I'm not convinced that shared subtrees as proposed will work well > with autofs. > > >> OK. I've read the thread but haven't digested it so you'll have to put >> up with some stupid questions. > > > The idea discussed off-line was this: > > When you install an autofs mountpoint, on say /home, a daemon is started > to service the requests. As far as the admin is concerned, an fs is > mounted in the current namespace, call it namespaceA. The daemon > actually runs in it's one private namespace: call it namespaceB. > namespaceB receives a new autofs filesystem: call it autofsB. autofsB > is in it's own p-node. namespaceA gets an autofsA on /home as well, and > autofsA is 'owned' by autofsB's p-node. > > So: > > autofsB -> autofsB > and > autofsB -> autofsA > > Effectively, namespaceA has a private instance of autofsB in its tree. > > The problem is this: > > Assume /home/mikew is accessed in namespaceA. The daemon running in > namespaceB gets the event, and mounts an nfs vfsmount on autofsB. This > event is propagated back to autofsA. > > >> Which condition (or action) in the definition implies > >> autofsB -> autofsA > autofsB -> autofsA indicates that mount events are propagated from autofsB to autofsA. Eg: if you have two mounts (A, B) in the same p-node, then A -> B and B -> A By definition, a mountpoint (A) alone in a one element p-node has the property: A -> A Which doesn't mean much, other than to show that A is in a p-node. If you have a p-node p' owned by p-node p, then all mountpoints i' in p' will have the following relationship with all mountpoints i in p: i -> i' but not the reverse (one-way relationship). > > (Problem 1: how do you block access to /home/mikew in namespaceA?) > > Next, a CLONE_NS is done in namespaceA, creating namespaceA'. the > homedir on /home/mikew is also copied. > > Now, in namespaceA', what happens when a user umount's /home/mikew? We > haven't yet determined how to handle umount event propagation, but it > appears likely that it will be *a hard thing to do*. > > >> No I haven't spent enough time on the RFC buy into this one. >> So I'll just say it looks like something is missing in this argument. > >> Perhaps the later is namespaceC? > Sure, it doesn't matter, namespaceA' is an arbitrary name. HTH, - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB/miHdQs4kOxk3/MRArCsAJ9PxyxE7crSRk4R0OMB4yppH10wpQCfeQO8 qk6kcExaN7rzJOi4KoRyXoY= =VvFb -----END PGP SIGNATURE----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
