Date: Sun, 21 Mar 2021 22:21:33 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "Youssef GHORBAL" <youssef.ghorbal@pasteur.fr>, Jason Breitman <jbreitman@tildenparkcapital.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: NFS Mount Hangs Message-ID: <YQXPR0101MB09684AB7BEFA911213604467DD669@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <D67AF317-D238-4EC0-8C7F-22D54AD5144C@pasteur.fr> References: <C643BB9C-6B61-4DAC-8CF9-CE04EA7292D0@tildenparkcapital.com> <3750001D-3F1C-4D9A-A9D9-98BCA6CA65A4@tildenparkcapital.com> <33693DE3-7FF8-4FAB-9A75-75576B88A566@tildenparkcapital.com>, <D67AF317-D238-4EC0-8C7F-22D54AD5144C@pasteur.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
--_002_YQXPR0101MB09684AB7BEFA911213604467DD669YQXPR0101MB0968_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Youssef GHORBAL <youssef.ghorbal@pasteur.fr> wrote:=0A=
>Hi Jason,=0A=
>=0A=
>> On 17 Mar 2021, at 18:17, Jason Breitman <jbreitman@tildenparkcapital.co=
m> wrote:=0A=
>>=0A=
>> Please review the details below and let me know if there is a setting th=
at I should apply to my FreeBSD NFS Server or if there is a bug fix that I =
can apply to resolve my issue.=0A=
>> I shared this information with the linux-nfs mailing list and they belie=
ve the issue is on the server side.=0A=
>>=0A=
>> Issue=0A=
>> NFSv4 mounts periodically hang on the NFS Client.=0A=
>>=0A=
>> During this time, it is possible to manually mount from another NFS Serv=
er on the NFS Client having issues.=0A=
>> Also, other NFS Clients are successfully mounting from the NFS Server in=
question.=0A=
>> Rebooting the NFS Client appears to be the only solution.=0A=
>=0A=
>I had experienced a similar weird situation with periodically stuck Linux =
NFS clients >mounting Isilon NFS servers (Isilon is FreeBSD based but they =
seem to have there >own nfsd)=0A=
Yes, my understanding is that Isilon uses a proprietary user space nfsd and=
=0A=
not the kernel based RPC and nfsd in FreeBSD.=0A=
=0A=
>We=92ve had better luck and we did manage to have packet captures on both =
sides >during the issue. The gist of it goes like follows:=0A=
>=0A=
>- Data flows correctly between SERVER and the CLIENT=0A=
>- At some point SERVER starts decreasing it's TCP Receive Window until it =
reachs 0=0A=
>- The client (eager to send data) can only ack data sent by SERVER.=0A=
>- When SERVER was done sending data, the client starts sending TCP Window =
>Probes hoping that the TCP Window opens again so he can flush its buffers.=
=0A=
>- SERVER responds with a TCP Zero Window to those probes.=0A=
Having the window size drop to zero is not necessarily incorrect.=0A=
If the server is overloaded (has a backlog of NFS requests), it can stop do=
ing=0A=
soreceive() on the socket (so the socket rcv buffer can fill up and the TCP=
window=0A=
closes). This results in "backpressure" to stop the NFS client from floodin=
g the=0A=
NFS server with requests.=0A=
--> However, once the backlog is handled, the nfsd should start to soreceiv=
e()=0A=
again and this shouls cause the window to open back up.=0A=
--> Maybe this is broken in the socket/TCP code. I quickly got lost i=
n=0A=
tcp_output() when it decides what to do about the rcvwin.=0A=
=0A=
>- After 6 minutes (the NFS server default Idle timeout) SERVER racefully c=
loses the >TCP connection sending a FIN Packet (and still a TCP Window 0)=
=0A=
This probably does not happen for Jason's case, since the 6minute timeout=
=0A=
is disabled when the TCP connection is assigned as a backchannel (most like=
ly=0A=
the case for NFSv4.1).=0A=
=0A=
>- CLIENT ACK that FIN.=0A=
>- SERVER goes in FIN_WAIT_2 state=0A=
>- CLIENT closes its half part part of the socket and goes in LAST_ACK stat=
e.=0A=
>- FIN is never sent by the client since there still data in its SendQ and =
receiver TCP >Window is still 0. At this stage the client starts sending TC=
P Window Probes again >and again hoping that the server opens its TCP Windo=
w so it can flush it's buffers >and terminate its side of the socket.=0A=
>- SERVER keeps responding with a TCP Zero Window to those probes.=0A=
>=3D> The last two steps goes on and on for hours/days freezing the NFS mou=
nt bound >to that TCP session.=0A=
>=0A=
>If we had a situation where CLIENT was responsible for closing the TCP Win=
dow (and >initiating the TCP FIN first) and server wanting to send data we=
=92ll end up in the same >state as you I think.=0A=
>=0A=
>We=92ve never had the root cause of why the SERVER decided to close the TC=
P >Window and no more acccept data, the fix on the Isilon part was to recyc=
le more >aggressively the FIN_WAIT_2 sockets (net.inet.tcp.fast_finwait2_re=
cycle=3D1 & >net.inet.tcp.finwait2_timeout=3D5000). Once the socket recycle=
d and at the next >occurence of CLIENT TCP Window probe, SERVER sends a RST=
, triggering the >teardown of the session on the client side, a new TCP han=
dchake, etc and traffic >flows again (NFS starts responding)=0A=
>=0A=
>To avoid rebooting the client (and before the aggressive FIN_WAIT_2 was >=
implemented on the Isilon side) we=92ve added a check script on the client =
that detects >LAST_ACK sockets on the client and through iptables rule enfo=
rces a TCP RST, >Something like: -A OUTPUT -p tcp -d $nfs_server_addr --spo=
rt $local_port -j REJECT >--reject-with tcp-reset (the script removes this =
iptables rule as soon as the LAST_ACK >disappears)=0A=
>=0A=
>The bottom line would be to have a packet capture during the outage (clien=
t and/or >server side), it will show you at least the shape of the TCP exch=
ange when NFS is >stuck.=0A=
Interesting story and good work w.r.t. sluething, Youssef, thanks.=0A=
=0A=
I looked at Jason's log and it shows everything is ok w.r.t the nfsd thread=
s.=0A=
(They're just waiting for RPC requests.)=0A=
However, I do now think I know why the soclose() does not happen.=0A=
When the TCP connection is assigned as a backchannel, that takes a referenc=
e=0A=
cnt on the structure. This refcnt won't be released until the connection is=
=0A=
replaced by a BindConnectiotoSession operation from the client. But that wo=
n't=0A=
happen until the client creates a new TCP connection.=0A=
--> No refcnt release-->no refcnt of 0-->no soclose().=0A=
=0A=
I've created the attached patch (completely different from the previous one=
)=0A=
that adds soshutdown(SHUT_WR) calls in the three places where the TCP=0A=
connection is going away. This seems to get it past CLOSE_WAIT without a=0A=
soclose().=0A=
--> I know you are not comfortable with patching your server, but I do thin=
k=0A=
this change will get the socket shutdown to complete.=0A=
=0A=
There are a couple more things you can check on the server...=0A=
# nfsstat -E -s=0A=
--> Look for the count under "BindConnToSes".=0A=
--> If non-zero, backchannels have been assigned=0A=
# sysctl -a | fgrep request_space_throttle_count=0A=
--> If non-zero, the server has been overloaded at some point.=0A=
=0A=
I think the attached patch might work around the problem.=0A=
The code that should open up the receive window needs to be checked.=0A=
I am also looking at enabling the 6minute timeout when a backchannel is=0A=
assigned.=0A=
=0A=
rick=0A=
=0A=
Youssef=0A=
=0A=
_______________________________________________=0A=
freebsd-net@freebsd.org mailing list=0A=
https://lists.freebsd.org/mailman/listinfo/freebsd-net=0A=
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A=
--_002_YQXPR0101MB09684AB7BEFA911213604467DD669YQXPR0101MB0968_
Content-Type: application/octet-stream; name="xprtdied.patch"
Content-Description: xprtdied.patch
Content-Disposition: attachment; filename="xprtdied.patch"; size=802;
creation-date="Sun, 21 Mar 2021 22:21:27 GMT";
modification-date="Sun, 21 Mar 2021 22:21:27 GMT"
Content-Transfer-Encoding: base64
LS0tIHN5cy9ycGMvc3ZjLmMueHBydGRpZWQJMjAyMS0wMy0yMCAxMzozNjo1MC43OTgzMzUwMDAg
LTA3MDAKKysrIHN5cy9ycGMvc3ZjLmMJMjAyMS0wMy0yMCAxNzozMDo0MS40NDgyNzAwMDAgLTA3
MDAKQEAgLTIwMyw2ICsyMDMsOCBAQCBzdmNwb29sX2NsZWFudXAoU1ZDUE9PTCAqcG9vbCkKIAkJ
bXR4X3VubG9jaygmZ3JwLT5zZ19sb2NrKTsKIAl9CiAJVEFJTFFfRk9SRUFDSF9TQUZFKHhwcnQs
ICZjbGVhbnVwLCB4cF9saW5rLCBueHBydCkgeworCQlpZiAoeHBydC0+eHBfc29ja2V0ICE9IE5V
TEwpCisJCQlzb3NodXRkb3duKHhwcnQtPnhwX3NvY2tldCwgU0hVVF9XUik7CiAJCVNWQ19SRUxF
QVNFKHhwcnQpOwogCX0KIApAQCAtMzg4LDYgKzM5MCw4IEBAIHhwcnRfdW5yZWdpc3RlcihTVkNY
UFJUICp4cHJ0KQogCXhwcnRfdW5yZWdpc3Rlcl9sb2NrZWQoeHBydCk7CiAJbXR4X3VubG9jaygm
Z3JwLT5zZ19sb2NrKTsKIAorCWlmICh4cHJ0LT54cF9zb2NrZXQgIT0gTlVMTCkKKwkJc29zaHV0
ZG93bih4cHJ0LT54cF9zb2NrZXQsIFNIVVRfV1IpOwogCVNWQ19SRUxFQVNFKHhwcnQpOwogfQog
CkBAIC0xMDc4LDYgKzEwODIsNyBAQCBzdmNfY2hlY2tpZGxlKFNWQ0dST1VQICpncnApCiAKIAlt
dHhfdW5sb2NrKCZncnAtPnNnX2xvY2spOwogCVRBSUxRX0ZPUkVBQ0hfU0FGRSh4cHJ0LCAmY2xl
YW51cCwgeHBfbGluaywgbnhwcnQpIHsKKwkJc29zaHV0ZG93bih4cHJ0LT54cF9zb2NrZXQsIFNI
VVRfV1IpOwogCQlTVkNfUkVMRUFTRSh4cHJ0KTsKIAl9CiAJbXR4X2xvY2soJmdycC0+c2dfbG9j
ayk7Cg==
--_002_YQXPR0101MB09684AB7BEFA911213604467DD669YQXPR0101MB0968_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQXPR0101MB09684AB7BEFA911213604467DD669>