All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Waychison <Michael.Waychison@Sun.COM>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] shared subtrees
Date: Tue, 18 Jan 2005 14:44:58 -0500	[thread overview]
Message-ID: <41ED673A.1010906@sun.com> (raw)
In-Reply-To: <20050117203926.GU26051@parcelfarce.linux.theplanet.co.uk>

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

Al Viro wrote:
> On Mon, Jan 17, 2005 at 03:11:18PM -0500, Mike Waychison wrote:
>  
> 
>>I don't think that solves the problem.  B should receive copies (with
>>shared semantics if called for) of all mountpoints C1,..,Cn that are
>>children of A if A->A.  This is regardless of whether or not propagation
>>occurs before or after the attach.
> 
> 
> ... when that makes sense.  Do you see any real problems with the proposed
> behaviour (i.e. propagation happens before attachment)?
> 
> BTW, you do realize that rbind also has "copy before attaching" semantics,
> right?

Ya, okay, that semantic will work.  Please add it to the RFC though :)

>  
> 
>>Allowing this is like allowing directory aliasing in the sense that an
>>aliased directory that is nested within itself opens us to
>>badness/headaches 8)
>>
>>I still think the only way to handle this is to disallow vfsmounts in a
>>p-node to have (grand)parent-child relationships.  This may have to be
>>extended to the 'owned by' case as well.
> 
> 
> Not feasible (and think what _that_ will do to --move, especially since
> propagation can span namespace boundaries).

Fair enough.

Changing the topic slightly: How should we handle propagation events for
the detach_mnt() case?  Is it fair to say: a detach_mnt of A mounted on
dentry d on parent B will 'umount -l Ai' all Ai where Ai is mounted on
dentry d in all peers and private derivatives of the p-node which B
belong to?

Steps to above:
- - Detaching A from parent B (mounted on dentry d)
  - Let S = set of all peer vfsmounts in B's p-node p (if any)
    unioned with all vfsmounts owned by p (expanding owned p-nodes
    recursively):
  - For each C in S
    - If (C has a child mountpoint D mounted on dentry d)
      && (D is equivalent to A)
      - umount -l D

Thoughts?

Also, brainstorming mountpoint expiry: How about something like this:

- - Each p-node has a recently-touched flag, like how vfsmount currently
has a mnt_expiry_mark.
- - A call to umount with MNT_EXPIRE of vfsmount A which is in a non-empty
p-node will:
  - Will check to see if *all* Ai in A's p-node (and derivatives) are
not busy, if not, return -EBUSY
  - Otherwise:
    - Will clear the recently-touched flag of the p-node if set
    - Otherwise it will umount all Ai.

This only works btw for autofs iff we have vfs native traps.  Otherwise
we'll need to do recursive MNT_EXPIRE (overload MNT_EXPIRE | MNT_DETACH?)

- --
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

iD8DBQFB7Wc6dQs4kOxk3/MRAo9/AJ415IkSmKqT7rpvo7Uwr8HZqI0okwCfXYs+
iuXoqlEyzGMCnPKwLlSfgvI=
=OAAC
-----END PGP SIGNATURE-----

  reply	other threads:[~2005-01-18 19:51 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 [this message]
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
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=41ED673A.1010906@sun.com \
    --to=michael.waychison@sun.com \
    --cc=bfields@fieldses.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.