linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Waychison <Michael.Waychison@Sun.COM>
To: Ram <linuxram@us.ibm.com>
Cc: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] shared subtrees
Date: Tue, 01 Feb 2005 02:02:29 -0500	[thread overview]
Message-ID: <41FF2985.8000903@sun.com> (raw)
In-Reply-To: <1107224911.8118.65.camel@localhost>

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

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?

- --
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/ymFdQs4kOxk3/MRAjuWAKCJfX+jZMUlm9ncM199Q0nJpxwPKQCgjQFE
VTNmwXtmKOLVlrqBd2AzfYk=
=tESv
-----END PGP SIGNATURE-----

  reply	other threads:[~2005-02-01  7:02 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-13 22:18 [RFC] shared subtrees Al Viro
2005-01-13 23:30 ` Mike Waychison
2005-01-14  0:19   ` Al Viro
2005-01-14  1:11 ` Erez Zadok
2005-01-14  1:38   ` Al Viro
2005-01-16  0:46 ` J. Bruce Fields
2005-01-16  0:51   ` Al Viro
2005-01-16 16:02 ` J. Bruce Fields
2005-01-16 18:06   ` Al Viro
2005-01-16 18:42     ` J. Bruce Fields
2005-01-17  6:11       ` Al Viro
2005-01-17 17:32         ` J. Bruce Fields
2005-01-25 21:07           ` Ram
2005-01-25 21:47             ` Mike Waychison
2005-01-25 21:55               ` J. Bruce Fields
2005-01-25 23:56                 ` Mike Waychison
2005-01-25 22:02               ` Ram
2005-02-01 23:37                 ` J. Bruce Fields
2005-02-02  1:37                   ` J. Bruce Fields
2005-02-01 23:21             ` J. Bruce Fields
2005-02-02 18:36               ` Ram
2005-02-02 19:45                 ` Mike Waychison
2005-02-02 20:33                   ` Ram
2005-02-02 21:08                     ` Mike Waychison
2005-02-02 21:25                       ` J. Bruce Fields
2005-02-02 21:33                         ` Mike Waychison
2005-02-02 21:48                           ` J. Bruce Fields
2005-04-05  9:37         ` Ram
2005-01-17 18:31 ` Mike Waychison
2005-01-17 19:00   ` J. Bruce Fields
2005-01-17 19:30     ` Mike Waychison
2005-01-17 19:32       ` J. Bruce Fields
2005-01-17 20:11         ` Mike Waychison
2005-01-17 20:39           ` Al Viro
2005-01-18 19:44             ` Mike Waychison
2005-01-17 21:21           ` J. Bruce Fields
2005-01-28 22:31 ` Mike Waychison
2005-01-29  4:40   ` raven
2005-01-31 17:19     ` Mike Waychison
2005-02-01  1:31       ` Ian Kent
2005-02-01  2:28   ` Ram
2005-02-01  7:02     ` Mike Waychison [this message]
2005-02-01 19:27       ` Ram
2005-02-01 21:15         ` Mike Waychison
2005-02-01 23:33           ` Ram
2005-02-02  2:10           ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41FF2985.8000903@sun.com \
    --to=michael.waychison@sun.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).