Date: Mon, 22 Aug 2005 13:18:46 -0700 From: Matthew Reimer <mreimer@vpop.net> To: arch@freebsd.org Subject: Re: [CFR] reflect resolv.conf update to running application Message-ID: <200508221318.46908.mreimer@vpop.net>
next in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Sat, 20 Aug 2005, Hajimu UMEMOTO wrote: > >> Our resolver reads resolv.conf once, and never re-read it. Recent >> OpenBSD changed to re-read resolv.conf when it is updated. I believe it >> is useful specially for mobile environment. So, I made a patch for our >> resolver. Please review it. > > Two concerns: > > (1) Has anyone characterized the significant of the cost of doing a stat() > for every DNS lookup for a significant workload? Does it matter? > Most performance-critical network paths don't do name lookups in > order to prevent indefinite stalls in lookup, but doing, say, 1,000 > additional stats a second is not a small issue. > > (2) By reading the configuration file more frequently and more quickly > after a change, we increase the chances of a race condition in which > the resolve reads a partially written resolv.conf file during an > update. Does this happen in practice? I've always been very leery > of re-reading configuration files automatically based on a > time-stamp, as updates to files are not atomic at all. How about just stat'ing resolv.conf if more than X seconds has passed since the last stat, rather than for every lookup? Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508221318.46908.mreimer>