On Wed, 2008-02-20 at 17:27 +0100, Miklos Szeredi wrote:
quoted text
> > On Wed, Feb 20, 2008 at 04:39:15PM +0100, Miklos Szeredi wrote:
> > > > 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.

I wonder, what is wrong in reporting mounts in other namespaces that
either receive and send propagation to mounts in our namespace?

If we take that approach, we will report **only** the mounts in other
namespace which have a counter part in our namespace. After all the
filesystems backing the mounts here and there are the same(other wise
they would'nt have propagated).

And any mounts contained outside our namespace, having no propagation
relation to any mounts in our namespace, will remain hidden. 

RP


quoted text
> 
> 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