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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
