shared subtrees implementation writeup

[Miklos Szeredi <miklos@szeredi.hu>]

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?

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.

Thanks,
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/