From owner-freebsd-stable@FreeBSD.ORG Mon Dec 22 15:06:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10A3E4B2 for ; Mon, 22 Dec 2014 15:06:58 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0B06843 for ; Mon, 22 Dec 2014 15:06:57 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DA5FDB9B1; Mon, 22 Dec 2014 10:06:56 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: NFS negative name caching and amd Date: Mon, 22 Dec 2014 10:04:48 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141221102746.GA11278@odi.ci.com.au> In-Reply-To: <20141221102746.GA11278@odi.ci.com.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412221004.48504.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 22 Dec 2014 10:06:56 -0500 (EST) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 15:06:58 -0000 On Sunday, December 21, 2014 5:27:46 am Richard Perini wrote: > > We're struggling with an NFS negative name caching issue that results in > a file created by an NFS client 'A' being invisible on client 'B' for up > to client A's negnametimeo value. In our scenario, a process on client > A creates a file, and passes a message to another process which may > run on client B. The second process expects the file created by A to > be available. Which NFS server are you using? If it is a FreeBSD NFS server, try changing vfs.timestamp_precision to 2 (or 3) and seeing if that reduces the amount of time you have to wait until the directory's ac timeout. Another possible the fix is to be careful to not open the file until you know it exists if you still want to keep the reduced LOOKUP RPC load from caching negative lookups. > We're running a mix of 9-stable and 10-stable machines, and the problem is > common to both. > > The obvious fix is to set the nfs mount option 'negnametimeo' to 0, but > unfortunately we also have 'amd' in the picture (which we also need in our > environment). Amd doesn't understand negnametimeo and ignores it, leaving > it set to the system default of 60 seconds (as shown by nfsstat -m). Have you tried autofs for 10-stable? Is it able to pass this option to NFS if you use it? If that works, I would prefer that to be the long term solution for this. I'm not a huge fan of adding kernel options to override each NFS default mount option if we can help it. -- John Baldwin