<div dir="ltr">As the adage goes, "It's not DNS, there's no way it's DNS..."<div><br></div><div>Easy enough to test, swap out the hostname for the direct IP and see if you still have the issue :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 22, 2022 at 9:39 AM Bill Kenworthy <<a href="mailto:billk@iinet.net.au">billk@iinet.net.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>A long shot ... dns issues?  I've seen a similar access pattern on a master/slave disk when one went flakey.<br><br>BillK<br><br><br><div class="gmail_quote">On 22 February 2022 9:19:53 am AWST, Brad Campbell <<a href="mailto:brad@fnarfbargle.com" target="_blank">brad@fnarfbargle.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<pre dir="auto">G'day all,<br><br>I have a relatively simple client/server system here with a central <br>server that exports a pile of stuff using NFSv4. No authentication.<br><br>This has been flawless since I upgraded from nfs v3 to v4 8-10 years ago.<br>After a "recentish" kernel update on the server, I've started to get <br>intermittent and hard to reproduce timeouts on the clients. No problem <br>on the server and all other clients remain responsive.<br><br>[ 2901.432422] nfs: server srv not responding, still trying<br>[ 2901.432423] nfs: server srv not responding, still trying<br>[ 2901.592410] nfs: server srv not responding, still trying<br>[ 2901.952426] nfs: server srv not responding, still trying<br>[ 2902.392426] nfs: server srv not responding, still trying<br>[ 2902.392432] nfs: server srv not responding, still trying<br>[ 2903.402412] nfs: server srv not responding, still trying<br>[ 2903.622411] nfs: server srv not responding, still trying<br>[ 2903.892413] nfs: server srv not responding, still trying<br>[ 2931.012132] nfs: server srv OK<br>[ 2931.012147] nfs: server srv OK<br>[ 2931.012220] nfs: server srv OK<br>[ 2931.012237] nfs: server srv OK<br>[ 2931.012243] nfs: server srv OK<br>[ 2931.012255] nfs: server srv OK<br>[ 2931.012285] nfs: server srv OK<br>[ 2931.012889] nfs: server srv OK<br>[ 2931.036638] nfs: server srv OK<br>[ 3129.162392] nfs: server srv not responding, still trying<br>[ 3129.162399] nfs: server srv not responding, still trying<br>[ 3129.702387] nfs: server srv not responding, still trying<br>[ 3130.262377] nfs: server srv not responding, still trying<br>[ 3130.412397] nfs: server srv not responding, still trying<br>[ 3130.482477] nfs: server srv not responding, still trying<br>[ 3130.912386] nfs: server srv not responding, still trying<br>[ 3130.912392] nfs: server srv not responding, still trying<br>[ 3131.412397] nfs: server srv not responding, still trying<br>[ 3131.912392] nfs: server srv not responding, still trying<br>[ 3157.574579] nfs: server srv OK<br>[ 3157.574654] nfs: server srv OK<br>[ 3157.574658] nfs: server srv OK<br>[ 3157.575214] nfs: server srv OK<br>[ 3157.575487] nfs: server srv OK<br>[ 3157.575496] nfs: server srv OK<br>[ 3157.575501] nfs: server srv OK<br>[ 3157.575977] nfs: server srv OK<br>[ 3157.631782] nfs: server srv OK<br>[ 3157.652340] nfs: server srv OK<br>[ 3176.012394] rpc_check_timeout: 1 callbacks suppressed<br>[ 3176.012407] nfs: server srv not responding, still trying<br>[ 3176.922393] nfs: server srv not responding, still trying<br>[ 3177.992389] nfs: server srv not responding, still trying<br>[ 3177.992393] nfs: server srv not responding, still trying<br>[ 3178.052380] nfs: server srv not responding, still trying<br>[ 3178.422382] nfs: server srv not responding, still trying<br>[ 3179.202386] nfs: server srv not responding, still trying<br>[ 3182.622375] nfs: server srv not responding, still trying<br>[ 3183.812376] nfs: server srv not responding, still trying<br>[ 3188.052371] nfs: server srv not responding, still trying<br>[ 3204.945036] call_decode: 1 callbacks suppressed<br>[ 3204.945051] nfs: server srv OK<br>[ 3204.945063] nfs: server srv OK<br>[ 3204.945176] nfs: server srv OK<br>[ 3204.945208] nfs: server srv OK<br>[ 3204.945224] nfs: server srv OK<br>[ 3204.945229] nfs: server srv OK<br>[ 3204.946453] nfs: server srv OK<br>[ 3205.035067] nfs: server srv OK<br>[ 3205.041453] nfs: server srv OK<br>[ 3205.048524] nfs: server srv OK<br><br>I do see this on the server when it happens :<br>[285997.760395] rpc-srv/tcp: nfsd: sent 509476 when sending 524392 bytes <br>- shutting down socket<br>[286884.809688] rpc-srv/tcp: nfsd: sent 131768 when sending 266344 bytes <br>- shutting down socket<br><br>So I know it's likely to be a network issue of some kind, but as it <br>happens on a VM on the same server it's not NIC related. There's no <br>firewall rules involved.<br><br>This happens to all clients having tried :<br>- A kvm VM on the server.<br>- My desktop<br>- My laptop<br>- A raspberry pi v4<br><br>The fault manifests with that particular client freezing all NFS I/O for <br>~10 minutes (the log example above was after mounting with -o timeo=10).<br><br>All using different kernels. I think it started sometime after Kernel <br>5.10.44 on the server, but I had a lot going on and my notes are "sparse".<br><br>Much reading intimates that a request from the client gets lost, and <br>things lock up until the client hits the timeout value and re-sends the <br>request. That is backed up by changing the mount timeout value.<br><br>My real problem is to reproduce it I need to move a significant amount <br>of traffic over the NFS connection, and that makes a packet trace using <br>tcpdump "a bit noisy".<br><br>If it were udp then I could understand a request going astray, but as <br>it's tcp I can only think it requires a connection drop/reconnect to do <br>that and I've not been able to capture one yet in a usable packet trace.<br><br>I'm building a test box to attempt to replicate it in a way I can <br>bisect, but as it can take an hour or to to manifest that's going to be <br>a very slow burn if I can reproduce it on the test hardware.<br><br>Unfortunately the server is a production machine, so I'm looking for <br>ideas on how one might debug it. Yes, I've searched, but it's not common <br>and there's potentially many causes. Any nfs gurus here?<br><br>Regards,<br><div>-- <br>An expert is a person who has found out by his own painful<br>experience all the mistakes that one can make in a very<br>narrow field. - Niels Bohr<hr>PLUG discussion list: <a href="mailto:plug@plug.org.au" target="_blank">plug@plug.org.au</a><br><a href="http://lists.plug.org.au/mailman/listinfo/plug" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>Committee e-mail: <a href="mailto:committee@plug.org.au" target="_blank">committee@plug.org.au</a><br>PLUG Membership: <a href="http://www.plug.org.au/membership" target="_blank">http://www.plug.org.au/membership</a><br></div></pre></blockquote></div><div style="white-space:pre-wrap"><div>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</div></div></div>_______________________________________________<br>
PLUG discussion list: <a href="mailto:plug@plug.org.au" target="_blank">plug@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/plug" rel="noreferrer" target="_blank">http://lists.plug.org.au/mailman/listinfo/plug</a><br>
Committee e-mail: <a href="mailto:committee@plug.org.au" target="_blank">committee@plug.org.au</a><br>
PLUG Membership: <a href="http://www.plug.org.au/membership" rel="noreferrer" target="_blank">http://www.plug.org.au/membership</a></blockquote></div>