On Thu, 2011-11-10 at 15:52 +0000, Andrew Cooper wrote: > > On 10/11/11 15:29, Chuck Lever wrote: > > On Nov 10, 2011, at 6:15 AM, Andrew Cooper wrote: > > > >> On 09/11/11 22:36, Chuck Lever wrote: > >>> On Nov 9, 2011, at 1:38 PM, Andrew Cooper wrote: > Sorry. I am not sure I was clear. An EIO does not present itself with > a hard mount, but a TCP FIN is still injected into the stream by the > client, causing 15 seconds of deadlock, eventually fixed by sending a > RST and restarting with a new TCP stream. At this point, softmounts > throw an EIO while hardmounts restart and continue successfully. > > My problem is not the EIO on softmount or lack of EIO for hardmout, but > the fact that the client sees fit to try and close the TCP stream while > an apparently otherwise healthy NFS session is ongoing. The client will attempt to close the TCP connection on any RPC level error. That can happen, e.g., if the server sends a faulty RPC/TCP record fragment header or some other garbage data. I'm assuming that you've checked that the TCP parameters are set to sane values for a 10GigE connection (i.e. tcp_timestamps is on) so that there is no corruption happening at that level? Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
