Messages in this thread | | | Date | Wed, 07 Jan 2004 16:13:08 -0500 | From | Mike Waychison <> | Subject | Re: [autofs] [RFC] Towards a Modern Autofs |
| |
H. Peter Anvin wrote:
> Mike Waychison wrote: > >> This is clearly not 'all of userspace'. Autofs is an exception. As >> is /etc/mtab. The way I see it, automounting is a 'mount facility', >> as are namespaces. The two should be made to work together. Yes, >> mount(8) should probably be fixed one way or another as well due to >> /etc/mtab breakage. Why? Because it too is a mount facility. >> >> There are a couple problems inherent with namespaces. Most of these >> are mount facilities that are broken such as mentioned above. They >> *should* be fixed to work nicely. > > > For that one needs to know how the namespaces are used, not just how > they are implemented. There was a long discussion on this on #kernel > yesterday, by the way. > The one between you and viro? I read the logs last night. I didn't see much discussion at all.
>> Other parts of userspace get confused with namespaces, eg: cron and >> atd. These programs clearly need infrastructure added that somehow >> allows for arbitrary namespace joining/saving. If you have >> suggestions for how we can solve this issue, please do let me know. >> I'm stumped :\ I'd be more than happy to discuss this with you. > > > Do they? In order for that to be a "clearly", I believe one needs to > understand how namespaces are used in practice. It may not be > desirable or even possible; this starts getting into a policy decision. > Yes. It is somewhat policy, but as it currently stands, the kernel not being able to give userspace the option is itself quite restricting.
>> One not-so-far fetched approach would be to associate cron/at jobs >> with automount configurations so that a namespace can be >> re-constructed at runtime. > > > I am not entirely sure what you mean with this, but it sounds > incredibly dangerous to me. > > Basically, consider Plan 9 namespaces (I admit I'm no expert on Plan 9 :). I'm told it allows one to somehow share namespaces with other users / processes as long as they exists. Linux has a per-process namespace model that (currently) doesn't allow this to happen. Once all processes that share a namespace die, the entire namespace ceases to exist. In order to 'reconstruct' a namespace, a service could somehow say: "Use this automount configuration" (manually by creating a fresh namespace, removing all non-essential mounts, and installing new mount-traps within this namespace).
This of course has corner cases like the chicken and egg problem where the configuration files have to be available in that namespace already, but with some thought we could figure that out. (Something similar to the way 2.6 uses rootfs could be used to strap into this fresh namespace, entirely from userspace).
This would in effect allow me to say "Take a snapshot of my namespace" (this would probably require more help from individual filesystem implementations in order to get all the mount information used) which would dump an automount map that could later be used to lazily recreate it.
Just a thought.
-- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[unhandled content-type:application/pgp-signature][unhandled content-type:application/pgp-signature] | |