> On Wed, Feb 20, 2008 at 04:39:15PM +0100, Miklos Szeredi wrote:
quoted text
> > > mountinfo - IMO needs a sane discussion of what and how should be shown
> > > wrt propagation state
> > 
> > Here's my take on the matter.
> > 
> > The propagation tree can be either be represented
> > 
> >  1) "from root to leaf" listing members of peer groups and their
> >  slaves explicitly,
> > 
> >  2) or "from leaf to root" by identifying each peer group and then for
> >  each mount showing the id of its own group and the id of the group's
> >  master.
> > 
> > 2) can have two variants:
> > 
> >  2a) id of peer group is constant in time
> > 
> >  2b) id of peer group may change
> > 
> > The current patch does 2b).  Having a fixed id for each peer group
> > would mean introducing a new object to anchor the peer group into,
> > which would add complexity to the whole thing.
> > 
> > All of these are implementable, just need to decide which one we want.
> 
> Eh...  Much more interesting question: since the propagation tree spans
> multiple namespaces in a lot of normal uses, how do we deal with
> reconstructing propagation through the parts that are not present in
> our namespace?  Moreover, what should and what should not be kept private
> to namespace?  Full exposure of mount trees is definitely over the top
> (it shows potentially sensitive information), so we probably want less
> than that.
> 
> FWIW, my gut feeling is that for each peer group that intersects with our
> namespace we ought to expose in some form
> 	* all vfsmounts belonging to that intesection
> 	* the nearest dominating peer group (== master (of master ...) of)
> that also has a non-empty intersection with our namespace
> 
> It's less about the form of representation (after all, we generate poll
> events when contents of that sucker changes, so one *can* get a consistent
> snapshot of the entire thing) and more about having it self-contained
> when we have namespaces in the play.
> 
> IOW, the data in there should give answers to questions that make sense.
> "Do events get propagated from this vfsmount I have to that vfsmount I have?"
> is a meaningful one; ditto for "are events here propagated to somewhere I
> don't see?" or "are events getting propagated here from somewhere I don't
> see?".

Well, assuming you see only one namespace.  When I'm experimenting
with namespaces and propagations, I see both (each in a separate
xterm) and I do want to know how propagation between them happens.

Your suggestion doesn't deal with that problem.

Otherwise, yes it makes sense to have a consistent view of the tree
shown for each namespace.  Perhaps the solution is to restrict viewing
the whole tree to privileged processes.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html