[lkml]   [2005]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: shared subtrees implementation writeup
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,
> Miklos

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-18 19:22    [W:0.046 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site