From owner-freebsd-arch Tue Feb 20 8:31:23 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 3FB3A37B401 for ; Tue, 20 Feb 2001 08:31:12 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 152CZ6DP; Tue, 20 Feb 2001 11:31:18 -0500 Reply-To: Randell Jesup To: Terry Lambert Cc: dillon@earth.backplane.com (Matt Dillon), bright@wintelcom.net (Alfred Perlstein), josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND References: <200102200122.SAA04466@usr05.primenet.com> From: Randell Jesup Date: 20 Feb 2001 11:31:52 -0500 In-Reply-To: Terry Lambert's message of "Tue, 20 Feb 2001 01:22:53 +0000 (GMT)" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert writes: >> :> cached state data is inherently bad everywhere, not just in DNS >> :> servers. >> : >> :You scare me, I was thinking just the same thing about mountd >> :earlier today. Only problem is that it violates POLA(* heh), one >> :could offer an command line option to have it watch the file. >> >> I was thinking just having a 'mountd -reload'. I don't like the >> idea of programs polling configuration files. I actually used a >> similar mechanism in Diablo and wound up having to add hacks to, >> for example, try to avoid catching a configuration file in the middle >> of being written out by an editor. >> >> A better way would be to take the 'vipw' concept and write a general >> system utility to edit configuration files that does the right thing >> when you write the config file out (heh heh... based on.... another >> config file!). > >You could close the file in between polls, and reopen it O_EXCL; >or your vipw suggestion would also work, using a two stage commit >to ensure that it was all or nothing for changes. > >Really, the program wants to sit on the file as part of its select >loop, and when the file is closed so that it's the sole opener again, >get an "exceptional condition" flagged in the select. > >Barring that, the next best thing is a signal, and the next best >after that is a poll. As an aside, we ran into this in AmigaDos as well. We cached all of our preferences (configuration) data in ramdisk files (which hardly took any space, since there was no block overhead, and guaranteed fast access). I then added notification commands to the filesystem, so applications could find out when the configuration changed. For fixed-size (binary) config files, you could simply make a single read, which became a ram-to-ram copy without very much overhead. For variable-sized files, a simple exclusive open and then read would do. Since these were all ram-to-ram copies, and the overhead on the Amiga of message passing and Open()/Read() was small, it worked well. >In an ideal system, you would change the host name one place (for an >example of commonly cached information), and everything would "just >know" and "just do the right thing". There's still a synchronization problem, even if the hostname is in shared memory, even if the write is atomic (a reader may be in the middle of reading the string). >Having an external program watching the configuration file changes >is really a very poor approach, since it doesn't address the >underlying problem very well. True. >A registry-like configuration store, which was cached by the OS, >and was referenced directly each time the data was needed, instead >of allowing the programs to cache data which might change would >really be the best approach, Fetching the data out of a kernel service on each access would be (potentially) a pretty major hit, performance-wise. Some form of registration of interest in the data would be better. Either something like the Amiga (get a signal/message/callback/whatever when it changes, then request the new information), or something that passes the notification along with the new data. The downside is that to change the data, you must also go through this procedure. The nice thing about the Amiga notification method was that you could use any tool to modify a preference (configuration option) - text editors, fancy GUI editors, copy (cp), etc. You could still provide this behavior if you made this configuration cache also act as a virtual FS, so you could call up (say) /config/hostname into vi, change it, then just save it. Or just copy another file over the existing one, etc. This kindof turns vipw on it's head. An alternative would be to leave everything in normal files, extend the vipw schema to lock arbitrary files (configedit), and then hook it into a notification method as per above. This loses the ability to use something like cp, but it allows arbitrary text editors, and hooks can be given to allow GUI programs to interact with a config file as well. > but I rather think that it would be >rejected because Microsoft had the idea. Heh. A new way to screw >over your competitors: make them so hateful that they refuse to >learn from your good ideas, and have to come up with something >gratuitously different (and probably more complicated) just to be >able to say that they aren't like you... :-) -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message