`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 oftheir corresponding master pnode, i.e p0 and p1 respectively. But in my example above they are also shared. And a shared mount could bebind mounted with propagation set in either direction. Hence theydeserve a separate pnode.  If it was just a slave mount then binding toit would not set any propagation and hence there need not be a separatepnodes 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 patchesthat I sent yesterday I did exactly that. It works. All that messyPNODE_UP,PNODE_DOWN,PNODE_MID is all gone. Code has becomemuch simpler.The reason this was there earlier was that I was thinking we may needall these phases for some operations like umount, make_mounted.. But as I understand the operations better I am convinced that it is notrequired, and you reconfirm that point :)Thanks,RP> > Thanks,> Miklos-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`