NFS shares no longer become unresponsive after a TCP connection is closed
Previously, NFS clients sometimes entered a 60 second
TIME_WAIT period after initiating the TCP disconnect sequence. This happened only when TCP timestamps were disabled on the connection. During the waiting period, the client was unable to reconnect the NFS TCP connection.
Due to waiting in the
TIME_WAIT period, the NFS mount points were unresponsive, an
rpciod kernel thread was using 100% CPU, and the
retrans number in the output of the
nfsstat -r command was becoming a very large number. In addition, NFS mounts with lower values of the
retrans options could cause I/O errors.
With this update, the NFS TCP connection is able to reconnect immediately after a disconnect sequence using a different source port. As a result, NFS mounts no longer become unresponsive and
rpciod no longer causes a high system load after a connection is closed. (BZ#1479043)