Re: [RFC] shared subtrees

From: Mike Waychison
Date: Mon Jan 31 2005 - 12:22:23 EST


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

Sorry for the bad quoting below:

raven@xxxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/