From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 02:07:52 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 E837416A41F for ; Sat, 27 Aug 2005 02:07:52 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail1.fluidhosting.com (mail1.fluidhosting.com [204.14.90.61]) by mx1.FreeBSD.org (Postfix) with SMTP id 0052243D48 for ; Sat, 27 Aug 2005 02:07:51 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 48920 invoked by uid 399); 27 Aug 2005 02:07:51 -0000 Received: from localhost (HELO ?192.168.1.100?) (dougb@dougbarton.net@127.0.0.1) by localhost with SMTP; 27 Aug 2005 02:07:51 -0000 Message-ID: <430FCAF5.90701@FreeBSD.org> Date: Fri, 26 Aug 2005 19:07:49 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hajimu UMEMOTO References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org 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: Sat, 27 Aug 2005 02:07:53 -0000 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