Under what circumstances does the new NFS client return EAGAIN?

Rick Macklem rmacklem at uoguelph.ca
Thu Mar 1 03:13:48 UTC 2012


Garrett Wollman wrote:
> <<On Wed, 29 Feb 2012 19:21:25 -0500 (EST), Rick Macklem
> <rmacklem at 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



More information about the freebsd-fs mailing list