Towards a Modern Autofs
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · H. Peter Anvin
A dead daemon is a
painful recovery, admitted. It is also a THIS SHOULD NOT HAPPEN condition. By cramming it into the kernel, you're in fact making the system less stable, not more, because the kernel being tainted with faulty code is a total system malfunction; a crashed userspace daemon is "merely" a messy cleanup. In practice, the autofs daemon/ does not die unless a careless system administrator kills it. It is a non-problem.
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.
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.
-Andi
Quoted 8 lines · Andi Kleen
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.
Quoted 3 lines
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
Quoted 6 lines · H. Peter Anvin
Quoted 3 lines
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.
Quoted 2 lines
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.
Signature · 11 lines
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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Quoted 10 lines · Mike Waychison
Quoted 6 lines · H. Peter Anvin
Quoted 3 lines
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...
Quoted 14 lines · Mike Fedyk
Quoted 10 lines · Mike Waychison
Quoted 6 lines · H. Peter Anvin
Quoted 3 lines
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.
Quoted 8 lines
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).
Quoted 1 line
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
Quoted 1 line · Mike Waychison
To put it into perspective, the I'm calling for the following major changes:
[...]
Quoted 1 line
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.
[...]
Quoted 3 lines
(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
Quoted 10 lines · Jeff Garzik
Quoted 1 line · Mike Waychison
To put it into perspective, the I'm calling for the following major changes:
[...]
Quoted 1 line
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.
[...]
Quoted 9 lines
Quoted 3 lines
(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?
Signature · 11 lines
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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Quoted 12 lines · Mike Waychison
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); } }
Quoted 1 line
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
Quoted 6 lines · Jeff Garzik
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 :)
Signature · 10 lines
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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Quoted 21 lines · Mike Waychison
Quoted 10 lines · Jeff Garzik
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.
Quoted 3 lines
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