From owner-freebsd-fs@FreeBSD.ORG Thu Mar 1 03:13:48 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 2E0621065672 for ; Thu, 1 Mar 2012 03:13:48 +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 E0D3C8FC08 for ; Thu, 1 Mar 2012 03:13:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKjoTk+DaFvO/2dsb2JhbAA9B4Unr1aBegEBBAEjVgUWGAICDRkCWQYTiAQFpzqSKIEviFmCcgUEBwMFBhYCAgUCCgEGBAcCBgcVCwkChEQBAjoaBQYBAgEDAwcBAQuCToEWBIhPjHCTD4E2CAk X-IronPort-AV: E=Sophos;i="4.73,507,1325480400"; d="scan'208";a="161609066" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Feb 2012 22:13:47 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 20A3CB3F65; Wed, 29 Feb 2012 22:13:47 -0500 (EST) Date: Wed, 29 Feb 2012 22:13:47 -0500 (EST) From: Rick Macklem To: Garrett Wollman Message-ID: <605429676.158764.1330571627121.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20302.54862.344852.13627@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.203] 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: Thu, 01 Mar 2012 03:13:48 -0000 Garrett Wollman wrote: > < said: > > > If you are using the "soft" or "intr" mount options, I'd suggest you > > get rid of them (technically "intr" should result in EINTR, but I > > wouldn't > > be surprised if an EWOULDBLOCK could pop out, as well). Also, you > > didn't mention whether you were using UDP or TCP mounts, although > > the > > above comments should apply to both. > > mount -t nfs -o ro,hard,tcp,nointr > > > You might also want to capture packets and look at them in > > wireshark, > > to make sure the EWOULDBLOCK isn't coming from the proprietary NAS > > server. > > Unfortunately, I can't capture packets on this machine fast enough to > record a decodeable NFS/TCP stream with the NAS. > Hmm. Well, for hard mounts the krpc shouldn't be returning EWOULDBLOCK. (It is conceivable that the server is returning this, but without a packet trace, I don't know how you could find out. I suppose you could put a "if (error == EWOULDBLOCK) printf(...);" in the code that decodes the NFS reply. If you'd like to do that, email and I'll come up with a quick patch.) 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. > Another bug I've noticed: when mounting any remote NFS filesystem, all > of the local exported NFS filesystems briefly give [EPERM] (or maybe > it's [EACCES]) errors to their clients. This tends to break whatever > is trying to use them at the time. It doesn't happen when local ZFS > datasets are created and mounted. > Personally, I'm not very fond of it, but "mount" forces mountd to redo the file exports whenever a new mount is done. (I believe the thinking was to make sure the newly mounted fs gets exported, if it is in /etc/exports, but I wasn't the author of it and I haven't looked at the commit log for mount.c.) You could easily hack mount.c to not do this. 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.) rick