From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: how to show propagation state for mounts Date: Wed, 20 Feb 2008 11:29:13 -0800 Message-ID: <1203535754.28525.14.camel@ram.us.ibm.com> References: <20080220160422.GY27894@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: viro@ZenIV.linux.org.uk, linux-fsdevel@vger.kernel.org To: Miklos Szeredi Return-path: Received: from e32.co.us.ibm.com ([32.97.110.150]:51520 "EHLO e32.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756706AbYBTT2O (ORCPT ); Wed, 20 Feb 2008 14:28:14 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m1KJRldN023006 for ; Wed, 20 Feb 2008 14:27:47 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m1KJS2AX203256 for ; Wed, 20 Feb 2008 12:28:02 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m1KJS2dT022309 for ; Wed, 20 Feb 2008 12:28:02 -0700 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 2008-02-20 at 17:27 +0100, Miklos Szeredi wrote: > > 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 > > Miklos