Date: Thu, 15 Apr 2021 21:07:21 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Allan Jude <allanjude@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Cc: Richard Scheffenegger <rscheff@FreeBSD.org>, Juraj Lutter <otis@FreeBSD.org> Subject: Re: NFS issues since upgrading to 13-RELEASE Message-ID: <YQXPR0101MB0968AACB68CC9D2C7ECF5B9BDD4D9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <YQXPR0101MB096883332B60E632ADA6F2A4DD4D9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <902a3c81-2ce8-49c0-b163-5ffa4b90afe5@www.fastmail.com>, <e8f585eb-a2a8-ae9d-7f33-526e412ec462@freebsd.org>, <YQXPR0101MB09681707D3F3DC10814A905BDD4D9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>, <YQXPR0101MB096883332B60E632ADA6F2A4DD4D9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Stupid Outlook...=0A= I wrote:=0A= [stuff snipped]=0A= >- Alternately you can try rscheff@'s alternate proposed patch that is at= =0A= > https://reviews.freebsd.og/D29690.=0A= Oops, that's=0A= https:/reviews.freebsd.org/D29690=0A= =0A= But you can figure out the link;-), rick=0A= =0A= rick=0A= =0A= I have not yet had time to test this one, but since I cannot reproduce th= e hang, I can=0A= only do testing of it to see that it is "no worse" than reverting r367492= for my=0A= setup.=0A= =0A= Please let us know which you choose and whether or not it fixes your proble= m.=0A= =0A= >> Any pointers for troubleshooting this? I've been looking through vmstat,= gstat, top, etc. when the problem occurs, but I haven't been able to pinpo= int the issue. I can get pcap, but it would be from the hosts, because I do= n't have a 10G tap or managed switch.=0A= >>=0A= >=0A= >run `nfsstat -d 1` and try to capture a few lines from before, during,=0A= >and after the stall, and that may provide some insight.=0A= >=0A= >Specifically, does the queue length grow, suggesting it is waiting on=0A= >the I/O subsystem, or does it just stop getting traffic all together.=0A= =0A= If the revert of r367492 does not fix the problem, monitor the TCP connecti= on(s)=0A= via "netstat -a" and, if possible, capture packets via=0A= tcpdump -s 0 -w hang.pcap host <nfs-client>=0A= or similar, run on the server.=0A= =0A= Ideally the tcpdump would be started before the "hang" occurs, but running= =0A= one while the hang is occurring (until after it recovers) could also be use= ful.=0A= =0A= Thanks for reporting this, rick=0A= =0A= --=0A= Allan Jude=0A= _______________________________________________=0A= freebsd-current@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= =0A= =0A= _______________________________________________=0A= freebsd-current@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB0968AACB68CC9D2C7ECF5B9BDD4D9>