Re: shared subtrees implementation writeup

[Ram Pai <linuxram@us.ibm.com>]

On Mon, 2005-07-18 at 04:06, Miklos Szeredi wrote:
> Thanks for the writeup, it helps to understand things a bit better.
> However I still don't understand a few things:
> 
> 
> > Section 1. mount:
> > 
> > 	to begin with we have a the following mount tree 
> > 
> > 		         root
> > 		      /	/  \  \ \
> > 		     /	t1  t2 \  \ 
> > 		   t0		t3 \
> > 				    t4
> > 
> > 	note: 
> > 	t0, t1, t2, t3, t4 all contain mounts.
> > 	t1 t2 t3 are the slave of t0. 
> > 	t4 is the slave of t2.
> > 	t4 and t3 is marked as shared.
> > 
> > 	The corresponding propagation tree will be:
> > 
> > 			p0
> > 		      /   \
> > 		     p1   p2
> > 		     /     
> > 	 	     p3	   
> > 
> > 
> > 	***************************************************************
> > 	      p0 contains the mount t0, and contains the slave mount t1
> > 	      p1 contains the mount t2
> > 	      p3 contains the mount t4
> > 	      p2 contains the mount t3
> > 
> > 	  NOTE: you may need to look at this multiple time as you try to
> > 	  	understand the various scenarios.
> > 	***************************************************************
> 
> Why you have p2 and p3?  They contain a single mount only, which could
> directly be slaves to p0 and p1 respectively.  Does it have something
> to do with being shared?

Yes. If the mounts were just slave than they could be a slave member of
their corresponding master pnode, i.e p0 and p1 respectively. But 
in my example above they are also shared. And a shared mount could be
bind mounted with propagation set in either direction. Hence they
deserve a separate pnode.  If it was just a slave mount then binding to
it would not set any propagation and hence there need not be a separate
pnodes to track the propagation.

Just for clarification:
1. a slave mount is represented as a slave member of a pnode.
2. a shared mount is represented as a member of a  pnode.
3. a slave as well as a shared mount is represented a member of
	separate pnode, which in itself is a slave pnode.
4. a private mount is not part of any pnode.
5. a unclone mount is also not part of any pnode.


> 
> BTW, is there a reason not to include the pnode info in 'struct
> vfsmount'?  That would simplify a lot of allocation error cases.
> 
> > 	The key point to be noted in the above set of operations is:
> > 	each pnode does three different operations corresponding to each stage.
> > 
> > 	A. when the pnode is encountered the first time, it has to create
> > 		a new pnode for its child mounts.
> > 	B. when the pnode is encountered again after it has traversed down
> > 	   each slave pnode, it has to associate the slave pnode's newly created
> > 	   pnode with the pnode's newly created pnode.
> > 	C. when the pnode is encountered finally after having traversed through
> > 		all its slave pnodes, it has to create new child mounts
> > 		for each of its member mounts.
> 
> Now why is this needed?  Couldn't each of these be done in a single step?
> 
> I still can't see the reason for having these things done at different
> stages of the traversal.

Yes. This can be done in a single step. And in fact in my latest patches
that I sent yesterday I did exactly that. It works. All that messy
PNODE_UP,PNODE_DOWN,PNODE_MID is all gone. Code has become
much simpler.

The reason this was there earlier was that I was thinking we may need
all these phases for some operations like umount, make_mounted.. 
But as I understand the operations better I am convinced that it is not
required, and you reconfirm that point :)

Thanks,
RP
> 
> Thanks,
> Miklos