Date: Wed, 29 Feb 2012 22:13:47 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Garrett Wollman <wollman@bimajority.org> Cc: freebsd-fs@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? Message-ID: <605429676.158764.1330571627121.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20302.54862.344852.13627@hergotha.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Wollman wrote: > <<On Wed, 29 Feb 2012 19:21:25 -0500 (EST), Rick Macklem > <rmacklem@uoguelph.ca> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?605429676.158764.1330571627121.JavaMail.root>