Date: Fri, 26 Aug 2005 19:07:49 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Hajimu UMEMOTO <ume@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: [CFR] reflect resolv.conf update to running application Message-ID: <430FCAF5.90701@FreeBSD.org> In-Reply-To: <ygefyt4yiaz.wl%ume@mahoroba.org> References: <ygefyt4yiaz.wl%ume@mahoroba.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I've been following this thread with interest, and while I applaud the
effort that's gone into this I'm not sure it has a very high cost/benefit
ratio for the majority of FreeBSD systems. This would potentially be useful
for mobile systems that will often be moved into different networks, but
frankly I don't see a benefit for the vast majority of systems that will
have the same resolv.conf file for weeks, months, or years. I'm also
thinking of various types of high performance systems that actually do
thousands of DNS queries a minute. While a stat() call in the resolver path
for every query might not be noticeable on a "typical" system, they would
add up on systems that are already being stressed.
Personally, I would much rather we add some method of "HUPing" the resolver
to re-read resolv.conf. That way we could add that command to
dhclient-script and send it whenever the resolv.conf file is actually
changed. This could also be used by sysadmins for typically "static" systems
instead of having to restart services on those systems.
IF we go the route of dynamically re-reading the conf file (and I hope we
don't), then at minimum I think that the stat() and kqueue methods should be
benchmarked with as close to real world loads as possible.
hth,
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?430FCAF5.90701>