lkml.org 
[lkml]   [2005]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] shared subtrees
On Mon, 31 Jan 2005, Mike Waychison wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sorry for the bad quoting below:
>
> raven@themaw.net 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).

Sorry guys.

I've gota spend some time to get into this.
It is really important.

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

\
 
 \ /
  Last update: 2005-03-22 14:10    [W:0.075 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site