From: Tim Hockin <thockin@Sun.COM> To: "H. Peter Anvin" <hpa@zytor.com> Cc: Mike Waychison <Michael.Waychison@Sun.COM>, autofs mailing list <autofs@linux.kernel.org>, Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [autofs] [RFC] Towards a Modern Autofs Date: Tue, 6 Jan 2004 13:50:18 -0800 [thread overview] Message-ID: <20040106215018.GA911@sun.com> (raw) In-Reply-To: <3FFB223A.8000606@zytor.com> On Tue, Jan 06, 2004 at 01:01:46PM -0800, H. Peter Anvin wrote: > Finally, throwing out the daemon is a huge step backwards. Most of the > problems with autofs v3 (and to a lesser extent v4) are due to the > *lack* of state in userspace (the current daemon is mostly stateless); > putting additional state in userspace would be a benefit in my experience. Can you maybe share some details? I think this deign moves MORE state to userspace (expiry aside). The "state" in kernel is really mostly sent back to userspace. No more passing pipes into the kernel (state) or tracking the pgid of the daemon (state). > Pardon me for sounding harsh, but I'm seriously sick of the oft-repeated > idiocy that effectively boils down to "the daemon can die and would lose > its state, so let's put it all in the kernel." A dead daemon is a > painful recovery, admitted. It is also a THIS SHOULD NOT HAPPEN But it *does* 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 I don't think this design crams anything into the kernel. It doesn't put a whole lot more into the kernel than is currently in there (expiry and new mount stuff, aside). All the work still happens in userland. The daemon as it stands does NOT handle namespaces, does NOT handle expiry well, and is a pretty sad copy of an old design. > "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 have some customers I'd love to send to you, if you really think that's true.
WARNING: multiple messages have this Message-ID (diff)
From: Tim Hockin <thockin@Sun.COM> To: "H. Peter Anvin" <hpa@zytor.com> Cc: autofs mailing list <autofs@linux.kernel.org>, Mike Waychison <Michael.Waychison@Sun.COM>, Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [RFC] Towards a Modern Autofs Date: Tue, 6 Jan 2004 13:50:18 -0800 [thread overview] Message-ID: <20040106215018.GA911@sun.com> (raw) In-Reply-To: <3FFB223A.8000606@zytor.com> On Tue, Jan 06, 2004 at 01:01:46PM -0800, H. Peter Anvin wrote: > Finally, throwing out the daemon is a huge step backwards. Most of the > problems with autofs v3 (and to a lesser extent v4) are due to the > *lack* of state in userspace (the current daemon is mostly stateless); > putting additional state in userspace would be a benefit in my experience. Can you maybe share some details? I think this deign moves MORE state to userspace (expiry aside). The "state" in kernel is really mostly sent back to userspace. No more passing pipes into the kernel (state) or tracking the pgid of the daemon (state). > Pardon me for sounding harsh, but I'm seriously sick of the oft-repeated > idiocy that effectively boils down to "the daemon can die and would lose > its state, so let's put it all in the kernel." A dead daemon is a > painful recovery, admitted. It is also a THIS SHOULD NOT HAPPEN But it *does* 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 I don't think this design crams anything into the kernel. It doesn't put a whole lot more into the kernel than is currently in there (expiry and new mount stuff, aside). All the work still happens in userland. The daemon as it stands does NOT handle namespaces, does NOT handle expiry well, and is a pretty sad copy of an old design. > "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 have some customers I'd love to send to you, if you really think that's true.
next prev parent reply other threads:[~2004-01-06 21:52 UTC|newest] Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-01-06 19:55 [RFC] Towards a Modern Autofs Mike Waychison 2004-01-06 19:55 ` Mike Waychison 2004-01-06 21:01 ` [autofs] " H. Peter Anvin 2004-01-06 21:01 ` H. Peter Anvin 2004-01-06 21:44 ` [autofs] " Mike Waychison 2004-01-06 21:44 ` Mike Waychison 2004-01-06 21:50 ` Tim Hockin [this message] 2004-01-06 21:50 ` Tim Hockin 2004-01-06 22:06 ` [autofs] " H. Peter Anvin 2004-01-06 22:06 ` H. Peter Anvin 2004-01-06 22:17 ` [autofs] " Tim Hockin [not found] ` <20040106221502.GA7398@hockin.org> 2004-01-06 22:20 ` H. Peter Anvin 2004-01-06 22:20 ` H. Peter Anvin 2004-01-07 16:19 ` [autofs] " Mike Waychison 2004-01-07 16:19 ` Mike Waychison 2004-01-07 17:55 ` [autofs] " H. Peter Anvin 2004-01-07 21:13 ` Mike Waychison 2004-01-06 22:28 ` name spaces good (was: [autofs] [RFC] Towards a Modern Autofs) Dax Kelson 2004-01-06 22:48 ` name spaces good H. Peter Anvin 2004-01-06 22:48 ` H. Peter Anvin 2004-01-07 21:14 ` [autofs] [RFC] Towards a Modern Autofs Jim Carter 2004-01-07 21:14 ` Jim Carter 2004-01-07 22:55 ` [autofs] " Mike Waychison 2004-01-07 22:55 ` Mike Waychison 2004-01-08 12:00 ` [autofs] " Ian Kent 2004-01-08 12:00 ` Ian Kent 2004-01-08 15:39 ` [autofs] " Mike Waychison 2004-01-09 18:20 ` Ian Kent 2004-01-09 18:20 ` Ian Kent 2004-01-09 20:06 ` [autofs] " Mike Waychison 2004-01-09 20:06 ` Mike Waychison 2004-01-10 5:43 ` [autofs] " Ian Kent 2004-01-12 13:07 ` Mike Waychison 2004-01-12 16:01 ` raven 2004-01-12 16:26 ` Mike Waychison 2004-01-12 22:50 ` Tim Hockin 2004-01-12 23:28 ` Mike Waychison 2004-01-13 1:30 ` Ian Kent 2004-01-13 1:30 ` Ian Kent 2004-01-12 16:28 ` [autofs] " raven 2004-01-12 16:58 ` Mike Waychison 2004-01-13 1:54 ` Ian Kent 2004-01-13 1:54 ` Ian Kent 2004-01-13 19:01 ` [autofs] " Mike Waychison 2004-01-13 19:01 ` Mike Waychison 2004-01-14 15:58 ` [autofs] " raven 2004-01-14 19:32 ` running out of mount points Greg Bradner 2004-01-19 15:48 ` Greg Bradner 2004-01-19 17:11 ` Mike Waychison 2004-01-19 19:07 ` Greg Bradner 2004-01-20 19:15 ` Jim Carter 2004-01-13 18:46 ` [autofs] [RFC] Towards a Modern Autofs Mike Waychison 2004-01-13 18:46 ` Mike Waychison 2004-01-09 20:51 ` [autofs] " Jim Carter 2004-01-09 20:51 ` Jim Carter 2004-01-10 5:56 ` [autofs] " Ian Kent 2004-01-08 17:34 ` H. Peter Anvin 2004-01-08 19:41 ` Mike Waychison 2004-01-08 23:42 ` Michael Clark 2004-01-09 20:28 ` Mike Waychison 2004-01-09 20:28 ` Mike Waychison 2004-01-09 20:54 ` [autofs] " H. Peter Anvin 2004-01-09 20:54 ` H. Peter Anvin 2004-01-09 21:43 ` [autofs] " Mike Waychison 2004-01-09 21:43 ` Mike Waychison 2004-01-09 18:32 ` [autofs] " Ian Kent 2004-01-09 18:32 ` Ian Kent 2004-01-09 20:52 ` [autofs] " Mike Waychison 2004-01-09 20:52 ` Mike Waychison 2004-01-10 6:05 ` [autofs] " Ian Kent 2004-01-08 12:29 ` Olivier Galibert 2004-01-08 13:20 ` Robin Rosenberg 2004-01-08 16:23 ` Mike Waychison 2004-01-08 12:35 ` Ian Kent 2004-01-08 13:08 ` Ian Kent 2004-01-08 18:20 ` Jim Carter 2004-01-08 21:01 ` H. Peter Anvin 2004-01-08 0:48 ` Ian Kent 2004-01-08 0:48 ` Ian Kent 2004-01-06 22:28 [autofs] " Ogden, Aaron A. 2004-01-06 22:41 ` Mike Fedyk 2004-01-06 22:47 ` Tim Hockin 2004-01-06 22:53 ` Paul Raines 2004-01-07 23:14 ` Jim Carter 2004-01-07 23:32 ` H. Peter Anvin 2004-01-08 12:52 ` Ian Kent 2004-01-08 12:52 ` Ian Kent 2004-01-08 18:31 ` viro 2004-01-09 18:43 ` Ian Kent 2004-01-09 19:41 ` Mike Waychison 2004-01-09 19:57 ` H. Peter Anvin 2004-01-09 21:31 ` Mike Waychison 2004-01-09 21:36 ` H. Peter Anvin 2004-01-06 23:34 Ogden, Aaron A. 2004-01-06 23:47 ` Tim Hockin [not found] <1b5GC-29h-1@gated-at.bofh.it> [not found] ` <1b6CO-3v0-15@gated-at.bofh.it> 2004-01-07 4:21 ` Andi Kleen 2004-01-07 17:50 ` H. Peter Anvin 2004-01-07 21:04 ` Mike Waychison 2004-01-07 21:11 ` Mike Fedyk 2004-01-07 23:40 ` Jesper Juhl 2004-01-07 21:24 ` Jeff Garzik 2004-01-07 23:47 ` Mike Waychison 2004-01-07 23:56 ` Jeff Garzik 2004-01-12 16:57 ` Mike Waychison 2004-01-13 7:39 ` Ian Kent 2004-01-08 19:32 trond.myklebust 2004-01-08 19:41 ` H. Peter Anvin 2004-01-08 20:08 ` trond.myklebust 2004-01-08 21:13 ` H. Peter Anvin 2004-01-08 22:20 ` J. Bruce Fields 2004-01-08 22:24 ` H. Peter Anvin 2004-01-09 20:37 ` Mike Waychison 2004-01-09 21:02 ` H. Peter Anvin 2004-01-09 21:52 ` Mike Waychison 2004-01-09 20:16 ` Mike Waychison
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040106215018.GA911@sun.com \ --to=thockin@sun.com \ --cc=Michael.Waychison@Sun.COM \ --cc=autofs@linux.kernel.org \ --cc=hpa@zytor.com \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.