From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 00:25:25 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 344901065675 for ; Fri, 2 Mar 2012 00:25:25 +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 E20F18FC18 for ; Fri, 2 Mar 2012 00:25:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAH8SUE+DaFvO/2dsb2JhbAA8B4U/r2iBfQEBBAEjVgUWGAICDRkCWQYTiAEFrVqKEIEviF2CKQoBCAUXAgIFAgoBBgQHAgYHFQsJAoREAQI6GgUGAQIBAwMHAQELglKBFgSIT4xskxCBNggO X-IronPort-AV: E=Sophos;i="4.73,514,1325480400"; d="scan'208";a="161752725" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 Mar 2012 19:25:24 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 21851B3F1F; Thu, 1 Mar 2012 19:25:24 -0500 (EST) Date: Thu, 1 Mar 2012 19:25:24 -0500 (EST) From: Rick Macklem To: Garrett Wollman Message-ID: <1549796645.224931.1330647924122.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20303.45967.708688.414986@hergotha.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Linux)/6.0.10_GA_2692) 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: Fri, 02 Mar 2012 00:25:25 -0000 Garrett Wollman wrote: > < 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. > Wow, those are big UDP datagrams, but if they work, cool... > rpc.lockd is running, for what it's worth. > Doesn't matter. With the "nolockd" option, the client mount never uses it. > > 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.) > Well, it happens to be easy to block all the nfsd threads when they are between processing of RPCs. There are times (not very frequent) when this is necessary for NFSv4, so the code is already there to do it. I don't know how to delay replies and that might be messy. I can resurrect the patch for you, because it is simply two new options on the nfssvc() syscall to suspend and resume the threads, that are done by mountd before/after updating exports. (I think the main concern is that, if mountd crashes while processing the exports update, the resume will never happen, at least not until mountd is restarted. I think rwatson@ had an additional concern when this was discussed at the BSDCan developer summit, but I can't recall what it was?) Just email if you want the patch to test, rick