Date: Tue, 20 Feb 2001 21:33:11 -0700 From: Wes Peters <wes@softweyr.com> To: Randell Jesup <rjesup@wgate.com> Cc: Terry Lambert <tlambert@primenet.com>, Matt Dillon <dillon@earth.backplane.com>, Alfred Perlstein <bright@wintelcom.net>, josb@cncdsl.com, arch@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <3A934507.A0645CF3@softweyr.com> References: <200102200122.SAA04466@usr05.primenet.com> <ybupugd2u4n.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Randell Jesup wrote:
>
> 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...
>
> :-)
We in the unix world have a well-founded aversion to storing configuration
information in binary data stores that can't be accessed via ed(1) when
the system is in single-user mode. If we wanted to stuff all the system
configuration into such a black hole, we could've done it with DBM data-
bases more than a decade ago, quite easily.
Yeah, yeah, this coming from the guy who uses PgSQL to store application
configuration data, but that box has no "single user mode", doesn't have
ed(1) on it, and doesn't really have a console either.
We are also smart enough to realize the difference between the piss-poor
implementation of the registry versus the piss-poor design.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.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?3A934507.A0645CF3>