Re: /etc/mtab and per-process namespaces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux