NFS mount returning EAGAIN

[Manuel Bouyer]

Hi,
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 "/home/builds/output/netbsd-5-0/200910250000Z/cats/binary/sets/comp.tgz": Resource temporarily unavailable (35)
And in dmesg on the client:
nfs server aa.bb.cc.dd:/NetBSD-daily: not responding
nfs server aa.bb.cc.dd:/NetBSD-daily: is alive again
nfs send error 35 for aa.bb.cc.dd:/NetBSD-daily
nfs server aa.bb.cc.dd:/NetBSD-daily: not responding
nfs server aa.bb.cc.dd:/NetBSD-daily: 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 1.173.4.3).
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 <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 1.173.4.3
diff -u -p -u -r1.173.4.3 nfs_socket.c
--- nfs_socket.c 6 Feb 2009 01:48:58 -0000 1.173.4.3
+++ 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);
 
  /*

[Manuel Bouyer]

On Tue, Oct 27, 2009 at 12:55:36PM +0100, Manuel Bouyer wrote:

> Hi,
> 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 "/home/builds/output/netbsd-5-0/200910250000Z/cats/binary/sets/comp.tgz": Resource temporarily unavailable (35)
> And in dmesg on the client:
> nfs server aa.bb.cc.dd:/NetBSD-daily: not responding
> nfs server aa.bb.cc.dd:/NetBSD-daily: is alive again
> nfs send error 35 for aa.bb.cc.dd:/NetBSD-daily
> nfs server aa.bb.cc.dd:/NetBSD-daily: not responding
> nfs server aa.bb.cc.dd:/NetBSD-daily: 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 1.173.4.3).
> 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.

commited, will request a pullup to netbsd-5
This has been tested successfully on the client where this problem
did show up.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@...
     NetBSD: 26 ans d'experience feront toujours la difference
--

[Matthias Scheler-2]

On Thu, Nov 05, 2009 at 01:01:05PM +0100, Manuel Bouyer wrote:
> commited, will request a pullup to netbsd-5
> This has been tested successfully on the client where this problem
> did show up.

I wonder whether this will fix PR bin/41259 as well. The error I saw
is different (EBUSY) but could be caused by the same thing.

        Kind regards

--
Matthias Scheler                                  http://zhadum.org.uk/

[Manuel Bouyer]

On Thu, Nov 05, 2009 at 03:25:14PM +0000, Matthias Scheler wrote:
> On Thu, Nov 05, 2009 at 01:01:05PM +0100, Manuel Bouyer wrote:
> > commited, will request a pullup to netbsd-5
> > This has been tested successfully on the client where this problem
> > did show up.
>
> I wonder whether this will fix PR bin/41259 as well. The error I saw
> is different (EBUSY) but could be caused by the same thing.

The patch explicitely test for EAGAIN; if the error is EBUSY it will
make it up to the userland.
--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@...
     NetBSD: 26 ans d'experience feront toujours la difference
--