Re: [RFC] shared subtrees

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(Hmm.. something is up with my quoting again..)

Ram wrote:
> On Mon, 2005-01-31 at 23:02, Mike Waychison wrote:
> 
> Ram wrote:
> 
>>On Fri, 2005-01-28 at 14:31, Mike Waychison wrote:
> 
> 
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
> 
>>>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.
> 
>>>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.
> 
> 
>>Mike, multiple parsing through the problem definition, still did not
>>make the problem clear. What problem is autofs trying to solve using
>>namespaces?
> 
>>My guess is you dont want to see a automount taking place in namespaceA,
>>when a automount takes place in namespaceB, even though
>>the automount-point is in a shared subtree?
> 
>>Sorry don't understand automount's requirement in the first place,
>>RP
> 
> The major concern for automounting is that currently, if you start an
> automount daemon in the primary namespace, and some process clones off
> into a new namespace with clone(CLONE_NS), then there is no way for the
> daemon running in the first namespace to automount (let alone expire)
> any mounts in the second namespace.  There doesn't exist a way for the
> daemon to mount(2) nor umount(2) across namespaces.
> 
> The proposed solution for this is to use shared and private subtrees to
> have the daemon run in it's own namespace, with the primary and any
> derivative namespaces inheriting the automounts.  I'm not convinced that
> it'd work though.
> 
> Does this clarify?
> 
> 
>> Yes it does clarify the problem and motivates the reason behind using
>> shared subtree.
> 
>> However going back to your original problem 1:
> 
>> you have a daemon running in namespaceB, and a process running in
>> namespaceA and it acceses a auto-mountpoint /home. 
> 
>> The expected behavior in this case should be: the autofs-daemon must
>> mount the corresponding device at that mount point '/home' on all 
>> existing namespaces(provided that part of the subtree is shared). Right?
>> So in this case it should mount the device in both the namespaces, i.e
>> namespaceA and namespaceB.  

Yes.  Sharing allows this to happen in a 'safe' way.  The daemon doesn't
have to know how many instances of '/home' exist.

>> But you seem to be saying that you want to
>> block the auto-mount in namespaceA?
> 

No.  I want to allow the mount.  However, if there are several shared
'/home' (through CLONE_NS or mount --bind), there remains the following
two key problems:

- - How do you expire the mounts and umount them?  (undefined with shared
subtrees thus far)
- - How do you handle the case where '/home/mikew' is automounted in all
instances of it, and then umounted in a single namespace.  Walking back
into '/home/mikew' in that namespace will trigger the daemon to mount
again, but the filesystem is already mounted in it's namespace.

I guess a solution to ponder is what if we included the following rule:

"An attempt to umount a vfsmount X will induce the umounting of all
vfsmounts in X's p-node as well as all vfsmounts/p-nodes 'owned' by said
p-node."

I'm not sure that is a desirable solution or even nice to implement.

- --
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//F3dQs4kOxk3/MRAtFwAJwJlbQiltnBFFzsZHNfYo4oRxXLtgCfZ6ny
AVcIOZ/BirLJtjK/CENMDxM=
=PS6I
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/