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