9:08 a.m.
Daniel,
Grasping at straws, I've tried both UDP and TCP mounts, and NFS v3 and v4,
and some other tweaks as I peruse the various ganesha*config man pages and
wonder to myself. You know, banging on everything, hoping I get lucky,
before I roll up my sleeves and do it the right but difficult way with
packet captures. :)
I am using TCP for NFS by default everywhere and have been for years.
The change to UDP was just for that one test and when it didn't change
anything for the better I have since reverted to TCP.
I'll repeat the test with TCP and NFS v3 again and see if it generates the
same logged error.
Todd
On Thu, 12 Mar 2020, Daniel Gryniewicz wrote:
> 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
>>
>
>