Trond Myklebust wrote:
On Sun, 2008-08-24 at 23:09 +0100, Ian Campbell wrote:
(added some quoting from previous mail to save replying twice)
On Sun, 2008-08-24 at 15:19 -0400, Trond Myklebust wrote:
On Sun, 2008-08-24 at 15:17 -0400, Trond Myklebust wrote:
>From the tcpdump, it looks as if the NFS server is failing to close the
socket, when the client closes its side. You therefore end up getting
stuck in the FIN_WAIT2 state (as netstat clearly shows above).
Is the server keeping the client in this state for a very long
period?
Well, it had been around an hour and a half on this occasion. Next time
it happens I can wait longer but I'm pretty sure I've come back from
time away and it's been wedged for at least a day. How long would you
expect it to remain in this state for?
The server should ideally start to close the socket as soon as it
receives the FIN from the client. I'll have a look at the code.
I don't think it should matter how long the connection stays in FIN WAIT,
the client should reconnect anyway.
Since the client seems to be the variable, I would think it might be an
issue with the client reconnect logic?
That said, 2.6.25 is when the server side transport switch logic went in.
Tom
Trond
--
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
--
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
