From owner-freebsd-arch@FreeBSD.ORG Sun Aug 21 05:05:28 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78EB516A41F; Sun, 21 Aug 2005 05:05:28 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id E51CC43D45; Sun, 21 Aug 2005 05:05:27 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:XEy4x/CvWqtqnRZmodDXx20AiXa+UzzMczEiFCxB8jME8yvwy3B3/pYiQZrlUE4i@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7L55FoB014958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Aug 2005 14:05:19 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 21 Aug 2005 14:05:15 +0900 Message-ID: From: Hajimu UMEMOTO To: Peter Jeremy In-Reply-To: <20050821040454.GP13959@cirb503493.alcatel.com.au> References: <20050821003536.P14178@fledge.watson.org> <20050821040454.GP13959@cirb503493.alcatel.com.au> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sun, 21 Aug 2005 14:05:20 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: arch@freebsd.org, Robert Watson Subject: Re: [CFR] reflect resolv.conf update to running application X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2005 05:05:28 -0000 Hi, >>>>> On Sun, 21 Aug 2005 14:04:54 +1000 >>>>> Peter Jeremy said: PeterJeremy> Overall, I think that having applications see changes to /etc/resolv.conf PeterJeremy> is a good idea. Thanks. PeterJeremy> On Sun, 2005-Aug-21 00:37:56 +0100, Robert Watson wrote: >(1) Has anyone characterized the significant of the cost of doing a stat() > for every DNS lookup for a significant workload? Does it matter? PeterJeremy> I wrote a short program to run stat("/etc/resolv.conf") in a loop. PeterJeremy> On a P-233 running 4.9, I got about 45000 iterations/sec. PeterJeremy> On a P-120 running 5.4, I got about 10500 iterations/sec. PeterJeremy> I don't think this matters - especially compared to the overheads PeterJeremy> involved in sending and receiving the DNS UDP packets. If you are PeterJeremy> stating the same name frequently, it will be in the name cache so PeterJeremy> the name lookups are fairly cheap. Yes, I think a cost for stat() is considerably low than actuall DNS lookup. >(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 had care to don't update during the critical path. For example, I didn't change to use _res_init() in res_send(). I have been using this patch for myself about 3 months without any problem. PeterJeremy> This could be more of an issue, though I have no idea whether it PeterJeremy> really is. The easy work-around is to avoid updates. Instead create PeterJeremy> /etc/resolv.conf.tmp and rename it. Yup, I forgot to mention. Our dhclient updates resolv.conf frequently even when it is not changed. I think it is redundant, and I applied following patch: Index: sbin/dhclient/dhclient-script diff -u sbin/dhclient/dhclient-script.orig sbin/dhclient/dhclient-script --- sbin/dhclient/dhclient-script.orig Fri Jun 10 12:41:18 2005 +++ sbin/dhclient/dhclient-script Wed Jun 29 06:13:14 2005 @@ -152,6 +152,11 @@ cat /etc/resolv.conf.tail >>/etc/resolv.conf.std fi + if diff /etc/resolv.conf.std /etc/resolv.conf >/dev/null 2>&1; then + rm -f /etc/resolv.conf.std + return 0 + fi + # In case (e.g. during OpenBSD installs) /etc/resolv.conf # is a symbolic link, take care to preserve the link and write # the new data in the correct location. I wish to commit this, too. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/