mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Mike Waychison <Michael.Waychison@Sun.COM>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] shared subtrees
Date: Fri, 14 Jan 2005 00:19:20 +0000	[thread overview]
Message-ID: <20050114001920.GJ26051@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <41E704AA.9000305@sun.com>

On Thu, Jan 13, 2005 at 06:30:50PM -0500, Mike Waychison wrote:
> > 1) each p-node corresponds to a group of 1 or more vfsmounts.
> > 2) there is at most 1 p-node containing a given vfsmount.
> > 3) each p-node owns a possibly empty set of p-nodes and vfsmounts
> > 4) no p-node or vfsmount can be owned by more than one p-node
> > 5) only vfsmounts that are not contained in any p-nodes might be owned.
> > 6) no p-node can own (directly or via intermediates) itself (i.e. the
> > graph of p-node ownership is a forest).
> > 
> > These guys define propagation:
> > 	a) if vfsmounts A and B are contained in the same p-node, events
> > propagate from A to B
> > 	b) if vfsmount A is contained in p-node p, vfsmount B is contained
> > in p-node q and p owns q, events propagate from A to B
> > 	c) if vfsmount A is contained in p-node p and vfsmount B is owned
> > by p, events propagate from A to B
> 
> How is (c) different from (a)? Is there a distinction between
> 'containing' and 'owning' here?

Yes.  See (3) and (1) above.  Consider the following:
p = {A, B}
p owns C

Then we have propagation between A and B _and_ from either to C.

> > 	* we can mark a subtree slave.  That removes all vfsmounts in
> > the subtree from their p-nodes and makes them owned by said p-nodes.
> > p-nodes that became empty will disappear and everything they used to
> > own will be repossessed by their owners (if any).
> 
> Would this be better read as "That removes each vfsmount A in the
> subtree from its respective p-node p and makes it contained by a new
> p-node p' (containing only A), and p' becomes 'owned' by p." ?

No.  "Belongs to a single-element p-node" != "doesn't belong to any
p-node".  The former means "share on copy" (and might have slaves).
The latter is noone's master.  Again, see the propagation rules and
behaviour on clone/rbind.

> > 	* if V is contained in some p-node p, A is placed into the same
> > p-node.  That may require merging one of the p-nodes we'd just created
> > with p (that will be the counterpart of the p-node containing the mountpoint).
> > 	* if V is owned by some p-node p, then A (or p-node containing A)
> > becomes owned by p.
> 
> I don't follow this.  I still don't see the distinction between being
> owned and being contained.  Also, for statements like 'A belongs to B',
> which is it?

"V owned by p" == "V is a slave of (equivelent) members of p"
"p contains V" == "V is one of the members of p, whatever happens to it
will happen to all of them".

"element belongs to set" means what it usually means ;-) (again, p-nodes
are sets of vfsmounts).

  reply	other threads:[~2005-01-14  0:28 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-13 22:18 Al Viro
2005-01-13 23:30 ` Mike Waychison
2005-01-14  0:19   ` Al Viro [this message]
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
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=20050114001920.GJ26051@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=Michael.Waychison@Sun.COM \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®