Date: Thu, 18 Mar 2021 12:42:21 +0000 From: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com> To: Rick Macklem <rmacklem@uoguelph.ca>, Jason Breitman <jbreitman@tildenparkcapital.com>, "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: AW: NFS Mount Hangs Message-ID: <SN4PR0601MB3728780CE9ADAB144B3B681486699@SN4PR0601MB3728.namprd06.prod.outlook.com> In-Reply-To: <YQXPR0101MB0968DC18E00833DE2969C636DD6A9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <C643BB9C-6B61-4DAC-8CF9-CE04EA7292D0@tildenparkcapital.com> <3750001D-3F1C-4D9A-A9D9-98BCA6CA65A4@tildenparkcapital.com>, <33693DE3-7FF8-4FAB-9A75-75576B88A566@tildenparkcapital.com> <YQXPR0101MB0968DC18E00833DE2969C636DD6A9@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
>>Output from the NFS Client when the issue occurs # netstat -an | grep=20 >>NFS.Server.IP.X >>tcp 0 0 NFS.Client.IP.X:46896 NFS.Server.IP.X:2049 = FIN_WAIT2 >I'm no TCP guy. Hopefully others might know why the client would be stuck = in FIN_WAIT2 (I vaguely recall this means it is waiting for a fin/ack, but = could be wrong?) When the client is in Fin-Wait2 this is the state you end up when the Clien= t side actively close() the tcp session, and then the server also ACKed the= FIN.=20 This will last for ~2 min or so, but is asynchronous. However, the same 4-t= uple can not be reused during this time. With other words, from the socket / TCP, a properly executed active close()= will end up in this state. (If the other side initiated the close, a passi= ve close, will not end in this state)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?SN4PR0601MB3728780CE9ADAB144B3B681486699>