From owner-freebsd-stable@FreeBSD.ORG Sun Dec 21 10:35:10 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 A20222C7 for ; Sun, 21 Dec 2014 10:35:10 +0000 (UTC) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mippet.ci.com.au", Issuer "Corinthian Engineering Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3997B20D8 for ; Sun, 21 Dec 2014 10:35:09 +0000 (UTC) Received: from odi.ci.com.au (odi.ci.com.au [192.168.1.7]) by mippet.ci.COM.AU (8.14.7/8.14.9/CE140428) with ESMTP id sBLARktF027125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 21 Dec 2014 21:27:46 +1100 (AEDT) (envelope-from rpp@ci.com.au) Received: from odi.ci.com.au (localhost [127.0.0.1]) by odi.ci.com.au (8.14.7/8.14.7) with ESMTP id sBLARk1f011308 for ; Sun, 21 Dec 2014 21:27:46 +1100 (EST) (envelope-from rpp@odi.ci.com.au) Received: (from rpp@localhost) by odi.ci.com.au (8.14.7/8.14.7/Submit) id sBLARkn6011307 for freebsd-stable@freebsd.org; Sun, 21 Dec 2014 21:27:46 +1100 (EST) (envelope-from rpp) Date: Sun, 21 Dec 2014 21:27:46 +1100 From: Richard Perini To: freebsd-stable@freebsd.org Subject: NFS negative name caching and amd Message-ID: <20141221102746.GA11278@odi.ci.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: Sun, 21 Dec 2014 10:35:10 -0000 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. 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). We have a workaround that involves adding this entry to /sys/conf/options: NFS_DEFAULT_NAMETIMEO opt_nfs.h and then setting it in our kernel config file: option NFS_DEFAULT_NEGNAMETIMEO=0 which changes the system default to disable NFS's negative name caching. This seemed far easier than hacking on amd :-( Is there a better solution to this issue? If not, would a friendly committer be able to add the NFS_DEFAULT_NAMETIMEO to /sys/conf/options and MFC it back to the 9 branch please? I will submit a PR if that is appropriate. Regards -- Richard Perini