11 is EAGAIN, which means the socket would have blocked.  This is strange, as 2.8 does blocking writes, so we should never get EAGAIN from a write.   That said, why are you using UDP mounts? TCP mounts are generally considered to be better in every way (and are the default), so you might want to try that as a workaround. Daniel On 3/11/20 11:17 PM, Todd Pfaff wrote:

Daniel,

Thanks for the guidance about logging.  I haven't done packet captures yet but this is what I'm seeing logged around the time of the error condition:

  11/03/2020 21:51:34 : epoch 5e6994c3 : nfs-server-hostname :   ganesha.nfsd-168948[svc_18] rpc :TIRPC :F_DBG :svc_dg_reply:   0x7f35640008c0 fd 13 sendmsg failed (will set dead)

  11/03/2020 21:51:34 : epoch 5e6994c3 : nfs-server-hostname :   ganesha.nfsd-168948[svc_18] complete_request :DISP :DEBUG :NFS   DISPATCHER: FAILURE: Error while calling svc_sendreply on a new request.   rpcxid=3984287200 socket=13 function:nfs3_read   client:::ffff:10.1.2.3 program:100003 nfs version:3 proc:6 errno: 11

and from the client's perspective nothing can be done with the nfs mount until the nfs-ganesha server is restarted.

Do you have any suggestions for a recommended tcpdump command line to capture all useful traffic?

Thanks, Todd