tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

NFS mount returning EAGAIN

on a netbsd-5 system, access to a NFS TCP mount occasionally returns
EWOULDBLOCK/EAGAIN to userland. This is a hard mount so it should not
happens. Here's the kind of errors we're seeing:
rsync: write failed on 
Resource temporarily unavailable (35)
And in dmesg on the client:
nfs server not responding
nfs server is alive again
nfs send error 35 for
nfs server not responding
nfs server is alive again

On the server there are:
nfsd send error 32
though I don't know if they're happening at the same time at this point.

I think the EWOULDBLOCK is returned to userland from nfs_request(),
itself getting it from nfs_send() at line 1144 (nfs_socket.c
After the nfs_send() nfs_request() waits for a reply if there was no
error, or if error was EPIPE. As when nfs_send() returns EWOULDBLOCK
it would have set R_MUSTRESEND (in this situation at last), I wonder
if nfs_request() should check for EWOULDBLOCK in addition to EPIPE,
and go to nfs_reply() in this case as well.

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference
Index: nfs_socket.c
RCS file: /cvsroot/src/sys/nfs/nfs_socket.c,v
retrieving revision
diff -u -p -u -r1.173.4.3 nfs_socket.c
--- nfs_socket.c        6 Feb 2009 01:48:58 -0000
+++ nfs_socket.c        27 Oct 2009 11:55:04 -0000
@@ -1157,7 +1157,7 @@ tryagain:
         * Wait for the reply from our send or the timer's.
-       if (!error || error == EPIPE)
+       if (!error || error == EPIPE || error == EWOULDBLOCK)
                error = nfs_reply(rep, lwp);

Home | Main Index | Thread Index | Old Index