From: Jim Carter <jimc@math.ucla.edu> To: "Ogden, Aaron A." <aogden@unocal.com> Cc: thockin@sun.com, "H. Peter Anvin" <hpa@zytor.com>, autofs mailing list <autofs@linux.kernel.org>, Mike Waychison <Michael.Waychison@sun.com>, Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: RE: [autofs] [RFC] Towards a Modern Autofs Date: Wed, 7 Jan 2004 15:14:58 -0800 (PST) [thread overview] Message-ID: <Pine.LNX.4.53.0401071440090.21436@simba.math.ucla.edu> (raw) In-Reply-To: <6AB920CC10586340BE1674976E0A991D0C6BE4@slexch2.sugarland.unocal.com> On Tue, 6 Jan 2004, Ogden, Aaron A. wrote: > If you've read this far, what I'm trying to say is that having userspace > related code remain in userland is a good thing since you can restart > the daemon if something goes wrong. Hear, hear. But... > If you move all of this to > kernel-space you can't do anything about it if there is a problem. In > Solaris there is a command called 'automount' that tells the kernel to > re-read the automount maps, perhaps it resets the autofs subsystem in > the kernel as well. If linux autofs had the same capability we might > not need the daemon, but until then, having the daemon in userland is a > good thing. To my mind the ideal design goes something like this: 1. you can mount a synthetic autofs filesystem on lots of directories, including subdirs of other autofs filesystems. 2. Whenever anything tries to access one of those directories (for a direct map) or one of its subdirs whether visible or not (indirect map), if nothing is mounted on it [and it hasn't been told by a special flag that it's non-mountable, see the /home/user/server{A,B} example], the autofs kernel module runs a script in user space (in the namespace context of the originally requesting process). Upon exit, if something is now mounted on the subdir, fine. Otherwise, ENOENT. The module is not required to know anything about autofs maps that the userspace helper may or may not consult. 3. Periodically the module should check if mounted filesystems are potentially unmountable (this seems to be inexpensive), and if so it should run the userspace helper to unmount them. If the unmount fails, the helper (not the kernel) should try to distinguish a race condition from a dead NFS server, and whether the mount will be viable once the server comes back. If not, it should be more aggressive than the present daemon in unmounting. At present the module carefully keeps up-to-date a last_used field and a timeout potentially different for each mount, but it's probably sufficient to merely poll all the mount points periodically all at once, perhaps with a one-time exemption when something is first mounted. And that's *all* the complexity that should be in the kernel. That's quite complex enough in my opinion. If the userspace helper needs state, it can lock and read/write a file. I don't really see the need for the autofs system to have state beyond "it's mounted". James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)
WARNING: multiple messages have this Message-ID (diff)
From: Jim Carter <jimc@math.ucla.edu> To: "Ogden, Aaron A." <aogden@unocal.com> Cc: autofs mailing list <autofs@linux.kernel.org>, Mike Waychison <Michael.Waychison@sun.com>, Kernel Mailing List <linux-kernel@vger.kernel.org>, "H. Peter Anvin" <hpa@zytor.com> Subject: RE: [RFC] Towards a Modern Autofs Date: Wed, 7 Jan 2004 15:14:58 -0800 (PST) [thread overview] Message-ID: <Pine.LNX.4.53.0401071440090.21436@simba.math.ucla.edu> (raw) In-Reply-To: <6AB920CC10586340BE1674976E0A991D0C6BE4@slexch2.sugarland.unocal.com> On Tue, 6 Jan 2004, Ogden, Aaron A. wrote: > If you've read this far, what I'm trying to say is that having userspace > related code remain in userland is a good thing since you can restart > the daemon if something goes wrong. Hear, hear. But... > If you move all of this to > kernel-space you can't do anything about it if there is a problem. In > Solaris there is a command called 'automount' that tells the kernel to > re-read the automount maps, perhaps it resets the autofs subsystem in > the kernel as well. If linux autofs had the same capability we might > not need the daemon, but until then, having the daemon in userland is a > good thing. To my mind the ideal design goes something like this: 1. you can mount a synthetic autofs filesystem on lots of directories, including subdirs of other autofs filesystems. 2. Whenever anything tries to access one of those directories (for a direct map) or one of its subdirs whether visible or not (indirect map), if nothing is mounted on it [and it hasn't been told by a special flag that it's non-mountable, see the /home/user/server{A,B} example], the autofs kernel module runs a script in user space (in the namespace context of the originally requesting process). Upon exit, if something is now mounted on the subdir, fine. Otherwise, ENOENT. The module is not required to know anything about autofs maps that the userspace helper may or may not consult. 3. Periodically the module should check if mounted filesystems are potentially unmountable (this seems to be inexpensive), and if so it should run the userspace helper to unmount them. If the unmount fails, the helper (not the kernel) should try to distinguish a race condition from a dead NFS server, and whether the mount will be viable once the server comes back. If not, it should be more aggressive than the present daemon in unmounting. At present the module carefully keeps up-to-date a last_used field and a timeout potentially different for each mount, but it's probably sufficient to merely poll all the mount points periodically all at once, perhaps with a one-time exemption when something is first mounted. And that's *all* the complexity that should be in the kernel. That's quite complex enough in my opinion. If the userspace helper needs state, it can lock and read/write a file. I don't really see the need for the autofs system to have state beyond "it's mounted". James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key)
next prev parent reply other threads:[~2004-01-07 23:15 UTC|newest] Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-01-06 22:28 [autofs] [RFC] Towards a Modern Autofs Ogden, Aaron A. 2004-01-06 22:28 ` Ogden, Aaron A. 2004-01-06 22:41 ` [autofs] " Mike Fedyk 2004-01-06 22:47 ` Tim Hockin 2004-01-06 22:53 ` Paul Raines 2004-01-06 22:53 ` Paul Raines 2004-01-07 14:05 ` Greg Wooledge 2004-01-07 23:14 ` Jim Carter [this message] 2004-01-07 23:14 ` Jim Carter 2004-01-07 23:32 ` [autofs] " H. Peter Anvin 2004-01-07 23:32 ` H. Peter Anvin 2004-01-08 12:52 ` [autofs] " 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 18:43 ` Ian Kent 2004-01-09 19:41 ` [autofs] " Mike Waychison 2004-01-09 19:41 ` Mike Waychison 2004-01-09 19:57 ` [autofs] " H. Peter Anvin 2004-01-09 19:57 ` H. Peter Anvin 2004-01-09 21:31 ` [autofs] " Mike Waychison 2004-01-09 21:31 ` Mike Waychison 2004-01-09 21:36 ` [autofs] " H. Peter Anvin 2004-01-09 21:36 ` H. Peter Anvin -- strict thread matches above, loose matches on Subject: below -- 2004-01-08 19:32 [autofs] " 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 [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-06 23:34 Ogden, Aaron A. 2004-01-06 23:47 ` Tim Hockin 2004-01-06 19:55 Mike Waychison 2004-01-06 21:01 ` [autofs] " H. Peter Anvin 2004-01-06 21:44 ` Mike Waychison 2004-01-06 21:50 ` Tim Hockin 2004-01-06 22:06 ` H. Peter Anvin 2004-01-06 22:17 ` Tim Hockin [not found] ` <20040106221502.GA7398@hockin.org> 2004-01-06 22:20 ` H. Peter Anvin 2004-01-07 16:19 ` Mike Waychison 2004-01-07 17:55 ` H. Peter Anvin 2004-01-07 21:13 ` Mike Waychison 2004-01-07 21:14 ` Jim Carter 2004-01-07 22:55 ` Mike Waychison 2004-01-08 12:00 ` Ian Kent 2004-01-08 15:39 ` Mike Waychison 2004-01-09 18:20 ` Ian Kent 2004-01-09 20:06 ` Mike Waychison 2004-01-10 5:43 ` 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-12 16:28 ` raven 2004-01-12 16:58 ` Mike Waychison 2004-01-13 1:54 ` Ian Kent 2004-01-13 19:01 ` Mike Waychison 2004-01-14 15:58 ` raven 2004-01-13 18:46 ` Mike Waychison 2004-01-09 20:51 ` Jim Carter 2004-01-10 5:56 ` 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:54 ` H. Peter Anvin 2004-01-09 21:43 ` Mike Waychison 2004-01-09 18:32 ` Ian Kent 2004-01-09 20:52 ` Mike Waychison 2004-01-10 6:05 ` 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
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=Pine.LNX.4.53.0401071440090.21436@simba.math.ucla.edu \ --to=jimc@math.ucla.edu \ --cc=Michael.Waychison@sun.com \ --cc=aogden@unocal.com \ --cc=autofs@linux.kernel.org \ --cc=hpa@zytor.com \ --cc=linux-kernel@vger.kernel.org \ --cc=thockin@sun.com \ /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.