Re: /etc/mtab and per-process namespaces

[Mike Waychison <mikew@google.com>]

Ram wrote:
> On Tue, Oct 04, 2005 at 12:14:47PM -0700, David Leimbach wrote:
>
> > Hmm no responses on this thread a couple days now.  I guess:
> >
> > 1) No one cares about private namespaces or the fact that they make
> > /etc/mtab totally inconsistent.
> > 2) Private Namespaces aren't important to anyone and will never be
> > robust unless someone who cares, like me, takes it over somehow.
> > 3) Everyone is busy with their own shit and doesn't want to deal with
> > me or mine right now.
> >
> > I'm seriously hoping it's 3 :).  2 Is acceptable too of course.  I
> > think this is important and I want to know more about the innards
> > anyway.  1 would make me sad as I think Linux can really show other
> > Unix's what-for here when it comes to showing off how good the VFS can
> > be.
>
>
> This becomes even more intresting when sharedsubtree gets added to 
> the equation. One would like to know all the mounts in its namesapace
> and than all the mounts it propagates to which could include mounts in 
> other namespaces too..
>
> I guess some interface that meets the following needs would eventually
> be needed:
>
> 1. what are all the mounts in  my namespace ?
> 	A. what are the attributes of each of the mounts?
> 		a. where is it mounted
> 		b. who is its parent  
> 		c. what is it mounted from
> 		d. what are the attributes of its mount
> 		e. what are its peer mounts (I suspect some kind 
> 					of identifier has
> 					to be associated with each mount)
> 		f. if it has a master mount where is it
> 		g. what are its slave mounts.at
> 		(note: e, f, g can point to mounts in other namespaces)
> 2. what are the attributes of my namespace?
> 	a. what is the parent namespace? ( I suspect some kind 
> 			of identifier has to associated 
> 			with each namespace, pid of the cloned
> 			process?)
> 	b. what are my children namespace?
>
> 3. which processes can access my namespace?
>
>
> And I don't think /etc/mtab can do a decent job with this, because it
> would not know where all the mounts propagate, when it attempts a mount.
> Only the kernel would know, and hence all the commands who depend on
> /etc/mtab may have to depend on some /proc or maybe /sysfs interface to
> do a descent job.

Or,  you bite the bullet and fix /proc/mounts and let distributions bind 
mount /proc/mounts over /etc/mtab.

Sun recognized this as a problem a long time ago and /etc/mnttab has 
been magic for quite some time now.

Add to this the fact that a textfile /etc/mtab is busted because it's 
whitespace seperated and pieces blows up and you do things like:

mount filer:/export/mikew "/home/Mike Waychison"

Mike Waychison
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/