Re: NFS mount returning EAGAIN

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--