Hi chuck, Thanks for your reply. Chuck Lever 写道: > On 03/04/2010 05:12 AM, Mi Jinlong wrote: >> Hi, >> Step4: [22:42:16] Write data to file >> [22:42:16] Write data success >> Step5: [22:42:16] Unlock file >> [22:46:30] Unlock file success. >> Step6: [22:46:30] Close file /mnt/nfs/file >> [22:46:30] Close fiel /mnt/nfs/file success >> >> The problem is at step5, unlock file takes 4 min, it's a long time >> than expected. >> When traceing the kernel, I find SUNRPC call call_connect timeout many >> times, >> one timeout is 1min. > > The kernel's TCP reconnect logic will retry until it succeeds, without > letting the upper level make progress. For some reason, it is having > difficulty reconnecting with your server. > >> I think it's a problem of kernel, but i don't know why, can someone >> help me ? > > # sudo rpcdebug -m rpc -s xprt trans After running this command, I got some important messages that I think. RPC: xs_connect delayed xprt for 3 seconds ... RPC: xs_connect delayed xprt for 6 seconds ... RPC: xs_connect delayed xprt for 12 seconds ... RPC: xs_connect delayed xprt for 24 seconds ... ... RPC: xs_connect delayed xprt for 300 seconds This message is printed at xs_connect, and the delay time is double there. IMO, when some data translate over through a socket, the socket should be released. But, it seems the socket isn't released through those messages above. Is it wrong, or there are some other reasons ? At the latest kernel, this bug was fix by patch "NFS/RPC: fix problems with reestablish_timeout and related code." But I don't sure about this. thanks, Mi Jinlong -- 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
