Talpey, Thomas wrote:
At 04:03 AM 6/11/2008, Peter Leckie wrote:
That's a good point you raise there I was looking to closely at the tcp
equivalent, the correct fix for this issue would be to implement a timer
function for NFS/RDMA pretty much identical to xs_udp_timer(), as follows:
Hmm, in fact that runs into a different issue - retransmitting over RDMA
isn't allowed, since it consumes server credits and therefore will eventually
overrun the connection's receive queue. I have a patch in my queue to
force a disconnect in fact, which is the appropriate action. I will send them
out soon, it's in with some other post-Connectathon work.
I think with your earlier patch to avoid the 5-second pause, the disconnect
action will be prompt and accurate. However, I would still be concerned why
the RPC was timing out in the first place. Was there an issue in the server?
So this is not a typical runtime issue it was just another reason the
NFS/RDMA client failed to reconnect after
the server disconnects us. Under this circumstance the client is stalled
on congestion and has not received the
disconnection event. So what both these patches do is allow the client
to try and resend another RPC, this causes
rpcrdma_conn_upcall() to be called with an event of
RDMA_CM_EVENT_CONNECT_ERROR which
then allows the xprt to be disconnected and reconnected. Without this
change what happens is the client sits there
for ever waiting for the congestion to drop.
This does ask another question why didn't the DREQ from the server cause
the xprt on the client to disconnect.
Umm I might try and reproduce this error and see what's happening.
Thanks,
Pete
--
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
