2004-01-07 17:56:13

by H. Peter Anvin

[permalink] [raw]
Subject: Re: [autofs] [RFC] Towards a Modern Autofs

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.

> 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.

> 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.

-hpa


2004-01-07 21:13:50

by Mike Waychison

[permalink] [raw]
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: [email protected]
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Attachments:
file:///tmp/nsmail.pgp (252.00 B)
(No filename) (251.00 B)
Download all attachments