Hi,
I have nfs server hung in CLOSE_WAIT state and the corresponding
nfs client hang in FIN_WAIT2 state. NFS client is not retrying as NFS
server isn't calling close() on the socket. The shutdown was initiated
by NFS client and its now waiting for NFS server to send its FIN.
Actually I am using old version here:
NFS server: 2.6.16 (sles10sp3)
NFS client: 2.6.27 (sles11)
I see sunrpc client code missing xs_tcp_schedule_linger_timeout() in 2.6.27:
case TCP_FIN_WAIT1:
/* The client initiated a shutdown of the socket */
xprt->connect_cookie++;
xprt->reestablish_timeout = 0;
set_bit(XPRT_CLOSING, &xprt->state);
smp_mb__before_clear_bit();
clear_bit(XPRT_CONNECTED, &xprt->state);
clear_bit(XPRT_CLOSE_WAIT, &xprt->state);
smp_mb__after_clear_bit();
xs_tcp_schedule_linger_timeout(xprt,
xs_tcp_fin_timeout); << This is missing in 2.6.27
break;
So its clear that if the above linger timeout had been there
in 2.6.27 the client would have connected back again. But why
nfs service (server) sunrpc logic (svc_recv) hasn't called close on its
part of the socket is yet not clear to me. I would like to know if
anyone has faced this issue and if there are any fixes which I can
individually pick.
If I do another mount from same NFS client and another
IP of same NFS server, things starts fine. So to make the
original IP of same NFS server work fine, restart of nfs server
will do. But I would like to know why the hang on the transport
from NFS server side.
Sorry in advance for the noise if expectation is to test with
recent kernels and report accordingly. I can't test with new
kernels.
Thanks,
Rajesh
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
