Re: [RFC PATCH 10/10] vfs: shared subtree documentation

[Al Viro]

On Fri, Sep 16, 2005 at 11:26:20AM -0700, Ram wrote:
> 
> Complete description of shared subtrees.

BTW, one note on naming: s/next_shared/next_peer/ would probably be a good
idea.

> +     --------------------------------------------------------------------
> +     |                          BIND MOUNT OPERATION                    |
> +     |******************************************************************|

> +     	Details follow:

Do they ever...  That's one hell of an overkill.  Moreover, there's a
nasty subtle point that needs to be dealt with: you are using "slave"
in two different meanings - "slave that is not shared" and "slave of".
Your case 7 (slave on shared) is very confusing because of that -
C becomes a slave of Z, but it also becomes shared.  Which is what
we want, but everything prior to that uses "slave" only for solitary
ones.

	* if 'A' is an unclonable mount, operation is invalid.
	  An unclonable mount cannot be bind mounted.

	* otherwise a new mount 'C' is created; it is a clone of 'A'.
	  It is mounted on mount 'B' at dentry 'b'.

	* if 'A' is a shared mount, 'C' is made a peer of 'A'; if 'A' is a
	  slave of 'Z', 'C' is made a slave of 'Z'.

	* if 'B' is a shared mount, new mounts 'C1', 'C2', ... are created
	  and mounted at 'b' on all mounts where 'B' propagates to.  A new
	  propagation tree is set containing all new mounts 'C', ..., 'Cn'
	  exactly with the same configuration as the propagation tree of 'B'.

Same comment about use of "slave" applies through the rest of text.  IMO
it's worth a discussion _before_ you get to description of operations,
I.e. your 6F would save a lot of confusion if it went before the rest.

> +	Only a slave mount can be made as 'shared and slave' by executing
> +	the following command
> +		mount --make-shared mount

... but 'shared and slave' can be created by binding a slave on shared.

> +	->mnt_slave_list links all the mounts to which this mount propagates to.
> +
> +	->mnt_slave links together all the slaves that its master mount
> +	propagates to.
> +
> +	->mnt_master points to the master mount from which this mount receives
> +	propagation.

Missing bit:
	(1) all peers have the same ->mnt_master
	(2) all vfsmounts with the same ->mnt_master sit on a cyclic list
anchored in ->mnt_master->mnt_slave_list and going through ->mnt_slave.
	Aside of (1) ->mnt_master can point to arbitrary (and possibly
different) members of master peer group.  IOW, to find all immediate slaves
of a peer group you need to go through _all_ ->mnt_slave_list of its members.
Conceptually it's just a single set - distribution among the individual
lists does not affect propagation or the way propagation tree is modified
by operations.

> +	A example propagation tree looks as shown in the figure below.
> +	[ NOTE: Though it looks like a forest, if we consider all the shared
> +	mounts as a conceptual entity called 'pnode', it becomes a tree]
s/mounts/& in a peer group/ - there's a whole lot of shared mounts out
there, most of them not related to each other.

BTW, discussion of loop prevention in MS_MOVE is worth adding.

One note on splitting this stuff: I suspect that it might end up with
doing pure sharing (i.e. only peer groups) first (split as now, but
much simpler), then a series adding slaves, then the rest.  In any
case, I would expect the final splitup to be considerably more than 10
chunks.  IME that's worth doing - time spent on such massage pays off
since one tends to get cleaner code out of it; stuff that got missed
while writing the thing in the first place.
-
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/