From owner-freebsd-arch@FreeBSD.ORG  Mon Aug 22 20:18:59 2005
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
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 6E47716A41F
	for <arch@freebsd.org>; Mon, 22 Aug 2005 20:18:59 +0000 (GMT)
	(envelope-from mreimer@vpop.net)
Received: from ring.vpop.net (ring.vpop.net [207.178.248.5])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 41A2343D46
	for <arch@freebsd.org>; Mon, 22 Aug 2005 20:18:59 +0000 (GMT)
	(envelope-from mreimer@vpop.net)
Received: from bilbo.vpop.net (bilbo.vpop.net [70.56.77.194])
	by ring.vpop.net (Postfix) with ESMTP id 09DABAFADFB
	for <arch@freebsd.org>; Mon, 22 Aug 2005 13:18:52 -0700 (PDT)
From: Matthew Reimer <mreimer@vpop.net>
Organization: VPOP Technologies, Inc.
To: arch@freebsd.org
Date: Mon, 22 Aug 2005 13:18:46 -0700
User-Agent: KMail/1.8.1
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200508221318.46908.mreimer@vpop.net>
Cc: 
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Aug 2005 20:18:59 -0000

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