From owner-freebsd-fs@FreeBSD.ORG Thu Mar 1 17:36:17 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7248F106566B for ; Thu, 1 Mar 2012 17:36:17 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 03B0D8FC1D for ; Thu, 1 Mar 2012 17:36:16 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.4/8.14.4) with ESMTP id q21HaFaI090513; Thu, 1 Mar 2012 12:36:15 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.4/8.14.4/Submit) id q21HaFei090510; Thu, 1 Mar 2012 12:36:15 -0500 (EST) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20303.45967.708688.414986@hergotha.csail.mit.edu> Date: Thu, 1 Mar 2012 12:36:15 -0500 From: Garrett Wollman To: Rick Macklem In-Reply-To: <605429676.158764.1330571627121.JavaMail.root@erie.cs.uoguelph.ca> References: <20302.54862.344852.13627@hergotha.csail.mit.edu> <605429676.158764.1330571627121.JavaMail.root@erie.cs.uoguelph.ca> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 01 Mar 2012 12:36:16 -0500 (EST) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu Cc: freebsd-fs@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:36:17 -0000 < said: > Otherwise, maybe rsync is doing byte range locking. You could add > "nolockd" to the mount options (which avoids using the NLM) and see > if that helps. That may well have done it, although I changed too many variables to be certain. -o udp,rsize=262144,wsize=262144,nolockd,hard,nointr seems to be working without error. rpc.lockd is running, for what it's worth. > Unfortunately it is a well known issue that updating exports > is not done atomically. (I had a patch that suspended the nfsd > threads while exports were being updated, but it was felt to > be risky and zack@ was going to come up with a patch to fix this, > but I don't think he has committed anything.) That might be something that we at least would need. You don't need to suspend all of the nfsd threads, just delay responding to any request that fails access control until the filter programming is done. We may actually need to do something like that, if this machine is to be usable as a file server. (Can't have our users' jobs randomly breaking just because an administrator mounted a new filesystem.) -GAWollman