From owner-freebsd-arch@FreeBSD.ORG Fri Oct 23 14:43:33 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09FB0106568B; Fri, 23 Oct 2009 14:43:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 999358FC22; Fri, 23 Oct 2009 14:43:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA9e4UqDaFvJ/2dsb2JhbADZT4Q/BA X-IronPort-AV: E=Sophos;i="4.44,612,1249272000"; d="scan'208";a="52614119" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 23 Oct 2009 10:43:30 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 98AC7FB80E6; Fri, 23 Oct 2009 10:43:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8bryNq6sAb4; Fri, 23 Oct 2009 10:43:30 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 8FFABFB8012; Fri, 23 Oct 2009 10:43:30 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n9NEoPN17740; Fri, 23 Oct 2009 10:50:25 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 23 Oct 2009 10:50:25 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Bruce Evans In-Reply-To: <20091024010347.D14674@delplex.bde.org> Message-ID: References: <200910191634.30040.jhb@freebsd.org> <20091022182943.P13634@delplex.bde.org> <20091024010347.D14674@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, John Baldwin Subject: Re: Put a timeout on -ve name cache entries in NFS 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: Fri, 23 Oct 2009 14:43:33 -0000 On Sat, 24 Oct 2009, Bruce Evans wrote: > On Thu, 22 Oct 2009, Rick Macklem wrote: > >> On Thu, 22 Oct 2009, Bruce Evans wrote: >>> One reason that I never committed my port of NetBSD's implementation of >>> negative cache entries for nfs is that I thought the timeout should be >>> a mount option but I didn't want to deal with the portability problems >>> from that. >>> >> Just to clarify. Are you saying that, given no other system has such >> a mount option, you think the sysctl variable is an ok solution or >> that you think it should be a mount option and not a sysctl variable? > > No; I think it should be a mount option. > Ok, so then what were your concerns w.r.t "portability problems"? (It's not that much work to make it a mount option and since it looks like the patch will be delayed until after 8.0 releases, I/or John can make it a mount option but I didn't understand what you meant by "portability options".) [good stuff w.r.t. which is harder, deleted for brevity] > > My version actually just uses a hackish sysctl vfs.nfs.negcache (default: > enabled) to enable the negative name cache. I don't have any timeout > control for it. > Yea, I saw it mainly as a way to disable -ve caching too. It just happened that the sysctl variable could specify the timeout as well as disable it (if set == 0). When it comes to a mount option, an enable/disable flag is probably easier, but then there might be a debate along the lines of "An option shouldn't be enabled by default...", so I'm temped to stick with a setable timeout. Basically the current code has an "infinite" timeout and no way of disabling it, so it seemed to me that some sort of optional timeout/disable would be useful, so I suggested that to John. If no-one else weighs in on the other side, I head in the "mount option" direction, rick