tech-kern archive

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

Re: NFS mount returning EAGAIN

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 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.

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

Home | Main Index | Thread Index | Old Index