Date: 20 Feb 2001 11:31:52 -0500 From: Randell Jesup <rjesup@wgate.com> To: Terry Lambert <tlambert@primenet.com> Cc: dillon@earth.backplane.com (Matt Dillon), bright@wintelcom.net (Alfred Perlstein), josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <ybupugd2u4n.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Terry Lambert's message of "Tue, 20 Feb 2001 01:22:53 %2B0000 (GMT)" References: <200102200122.SAA04466@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <tlambert@primenet.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybupugd2u4n.fsf>