Andi Kleen wrote:
>
> I personally would be in favour of doing it all in the kernel because
> autofs3 and autofs4 are not fully compatible and break in subtle ways
> when not matching and in my experience when you have autofs3 compiled
> into the kernel the system happens to have an autofs 4 daemon
> installed and vice versa. Doing it in the kernel would avoid this
> nasty dependency problem.
>
"Don't do that then." Really. Originally the autofs v3 filesystem was
called "autofs" and the autofs v4 filesystem was called "autofs4" and
the intent was that you should *never* run them across versions.
Jeremy tried nevertheless to be compatible (mistake #1) and Linus then
renamed the autofs4 filesystem "autofs" (mistake #2). There was no good
reason for this and it should never have happened -- it broke the design
that was intended to make sure the above wasn't going to be a problem.
> Also when /home or other important fs are mounted via autofs there is
> not much practical difference between a hung kernel and a hung
> daemon. You have to reboot the system anyways.
a) Guess which one is easier to debug?
b) Do people around here really believe that putting things in the
kernel magically makes them work right?
-hpa
H. Peter Anvin wrote:
>> Also when /home or other important fs are mounted via autofs there is
>> not much practical difference between a hung kernel and a hung
>> daemon. You have to reboot the system anyways.
>
>
> a) Guess which one is easier to debug?
When they may both equally hang your machine, neither.
> b) Do people around here really believe that putting things in the
> kernel magically makes them work right?
>
No magic involved.
When atomicity is needed wrt. mountpoints, moving the logic into the
kernel is a much simpler solution.
How much code was required to handle the corner cases and races in the
existing autofs implementations?
To put it into perspective, the I'm calling for the following major changes:
1) move expiry logic out of autofs and into the VFS where others can use
it and notice when it breaks when VFS internals change. For example, I
just noticed that autofs4 in 2.6 hasn't been updated to grab the new
vfsmount_lock instead of dcache_lock in certain circumstances.
2) move the loop that used to spin around and ask kernelspace if there
was anything to expire into the VFS as well, where it won't be killed.
3) introduce some way to let userspace walk the mountpoints using file
descriptors as references.
4) figure out a way to get super_blocks to clone so that we can have
some consistent automount functionality across cloned namespaces.
(1) and (2) shouldn't be hard at all to do considering David Howells has
done the majority of this already. (3) is needed in order to manage
direct mounts properly for when they are 'covered'. Admittedly, (4)
comes off as an ugly hack.
Also, (2) was the only 'active' task the automount daemon was doing.
Everything else it did can be rewritten in the form of a usermode helper
that runs only when it is needed. This simplifies the userspace code a lot.
--
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Wed, Jan 07, 2004 at 04:04:41PM -0500, Mike Waychison wrote:
> H. Peter Anvin wrote:
>
> >>Also when /home or other important fs are mounted via autofs there is
> >>not much practical difference between a hung kernel and a hung
> >>daemon. You have to reboot the system anyways.
> >
> >
> >a) Guess which one is easier to debug?
>
> When they may both equally hang your machine, neither.
Let's see.
If it's in userspace, then setup your debug area in an area your system
doesn't depend on, and wham, the hang won't affect the entire system anymore.
Also, if you have /home automounted then it only affects the users on /home,
and root's $home should be /home...
Though, you can debug in-kernel code with UML...
Mike Waychison wrote:
> To put it into perspective, the I'm calling for the following major
> changes:
[...]
> 2) move the loop that used to spin around and ask kernelspace if there
> was anything to expire into the VFS as well, where it won't be killed.
[...]
> (1) and (2) shouldn't be hard at all to do considering David Howells has
> done the majority of this already. (3) is needed in order to manage
> direct mounts properly for when they are 'covered'. Admittedly, (4)
> comes off as an ugly hack.
>
> Also, (2) was the only 'active' task the automount daemon was doing.
> Everything else it did can be rewritten in the form of a usermode helper
> that runs only when it is needed. This simplifies the userspace code a
> lot.
Just going by your own explanation here, #2 should not be in the kernel.
If we moving daemons into the kernel just because they won't be killed,
we'll have Oracle in-kernel before you know it. Completely spurious reason.
Jeff
On Wed, 7 Jan 2004, Mike Fedyk wrote:
> On Wed, Jan 07, 2004 at 04:04:41PM -0500, Mike Waychison wrote:
> > H. Peter Anvin wrote:
> >
> > >>Also when /home or other important fs are mounted via autofs there is
> > >>not much practical difference between a hung kernel and a hung
> > >>daemon. You have to reboot the system anyways.
> > >
> > >
> > >a) Guess which one is easier to debug?
> >
> > When they may both equally hang your machine, neither.
>
> Let's see.
>
> If it's in userspace, then setup your debug area in an area your system
> doesn't depend on, and wham, the hang won't affect the entire system anymore.
>
> Also, if you have /home automounted then it only affects the users on /home,
> and root's $home should be /home...
>
>From a user point of view I have to agree with you. Keeping it out of the
kernel makes perfect sense to me.
Easier to test your setup - errors will not hang the box.
In the case the implementation is buggy a daemon can easily be restarted
nightly without disrupting other things running on the box (a nightly
reboot is not as friendly).
>From a developer point of view, I also agree.
Debugging kernel code is in general a much harder thing to do than
debugging a userspace daemon. I'd also guess that more people will be
inclined to contribute development time to a userspace program than a
kernel based implementation - just the fact that it's in-kernel will be
percieved as having a much higher barrier-to-entry and I suspect that fact
alone might discourage potential contributers.
- Jesper Juhl
Jeff Garzik wrote:
> Mike Waychison wrote:
>
>> To put it into perspective, the I'm calling for the following major
>> changes:
>
> [...]
>
>> 2) move the loop that used to spin around and ask kernelspace if there
>> was anything to expire into the VFS as well, where it won't be killed.
>
> [...]
>
>> (1) and (2) shouldn't be hard at all to do considering David Howells
>> has done the majority of this already. (3) is needed in order to
>> manage direct mounts properly for when they are 'covered'.
>> Admittedly, (4) comes off as an ugly hack.
>>
>> Also, (2) was the only 'active' task the automount daemon was doing.
>> Everything else it did can be rewritten in the form of a usermode
>> helper that runs only when it is needed. This simplifies the
>> userspace code a lot.
>
>
> Just going by your own explanation here, #2 should not be in the kernel.
>
> If we moving daemons into the kernel just because they won't be killed,
> we'll have Oracle in-kernel before you know it. Completely spurious
> reason.
>
You wouldn't put a bdflush daemon in userspace either would you? The
loop in question is just that; (overly simplified):
while (1) {
f = ask_kernel_if_anything_looks_inactive();
if (f) {
try_to_umount(f);
continue;
} else {
sleep(x seconds);
}
}
My point is, if this is the only active action done by userspace, why
open it up to being broken?
--
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Waychison wrote:
> You wouldn't put a bdflush daemon in userspace either would you? The
> loop in question is just that; (overly simplified):
>
> while (1) {
> f = ask_kernel_if_anything_looks_inactive();
> if (f) {
> try_to_umount(f);
> continue;
> } else {
> sleep(x seconds);
> }
> }
>
> My point is, if this is the only active action done by userspace, why
> open it up to being broken?
You're still using arguments -against- putting software in the kernel.
You don't decrease software's chances of "being broken" by putting it in
the kernel, the opposite occurs -- you increase the likelihood of making
the entire system unstable. This is one point that Solaris and Win32
have both missed :)
Jeff
Jeff Garzik wrote:
>
>
> You're still using arguments -against- putting software in the kernel.
> You don't decrease software's chances of "being broken" by putting it
> in the kernel, the opposite occurs -- you increase the likelihood of
> making the entire system unstable. This is one point that Solaris and
> Win32 have both missed :)
>
> Jeff
>
I get what you're saying. :)
However, doing so achieves two goals:
- I want kernelspace to provide mechanism, and let userspace define
policy. In this case, the policy is even finer grained than what we had
before and can be set at trigger time, rather than at initscript start time.
- I want to get rid of the old ioctl poll interface that didn't work
in namespaces.
The namespace problem effectively limits what we can do in userspace to
simply prodding the kernel to tell _it_ to unmount stuff. A daemon
alone cannot unmount across namespaces.
I hope this clarifies where I stand :)
--
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Mon, 12 Jan 2004, Mike Waychison wrote:
> Jeff Garzik wrote:
>
> >
> >
> > You're still using arguments -against- putting software in the kernel.
> > You don't decrease software's chances of "being broken" by putting it
> > in the kernel, the opposite occurs -- you increase the likelihood of
> > making the entire system unstable. This is one point that Solaris and
> > Win32 have both missed :)
> >
> > Jeff
> >
> I get what you're saying. :)
>
> However, doing so achieves two goals:
> - I want kernelspace to provide mechanism, and let userspace define
> policy. In this case, the policy is even finer grained than what we had
> before and can be set at trigger time, rather than at initscript start time.
> - I want to get rid of the old ioctl poll interface that didn't work
> in namespaces.
>
> The namespace problem effectively limits what we can do in userspace to
> simply prodding the kernel to tell _it_ to unmount stuff. A daemon
> alone cannot unmount across namespaces.
Another important consideration is "can implementing this functionality be
significanly simplified by doing it within the kernel" or if
functionality is not otherwise able to be done in userspace. I believe
that these points were made in the original proposal.
Ian