From: "Lever, Charles" Subject: RE: NFS over TCP: random drop Date: Tue, 16 Mar 2004 08:21:18 -0800 Sender: nfs-admin@lists.sourceforge.net Message-ID: <482A3FA0050D21419C269D13989C61130435DD6E@lavender-fe.eng.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1B3HJp-0008FV-Vb for nfs@lists.sourceforge.net; Tue, 16 Mar 2004 08:21:29 -0800 Received: from mx01.netapp.com ([198.95.226.53]) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.30) id 1B3HJp-0003kV-6H for nfs@lists.sourceforge.net; Tue, 16 Mar 2004 08:21:29 -0800 To: "Olaf Kirch" Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: hi olaf- IMO it would be better to fix this in the client. overloaded servers of all kinds behave this way, and the client should deal with it. server cluster failover also behaves this way. if this is a soft mount, do you see "timing out" messages in the log? > -----Original Message----- > From: Olaf Kirch [mailto:okir@suse.de]=20 > Sent: Tuesday, March 16, 2004 6:12 AM > To: nfs@lists.sourceforge.net > Subject: [NFS] NFS over TCP: random drop >=20 >=20 > Hi, >=20 > I am looking into an NFS problem at one of our customers.=20 > They are running NFS over TCP, and the client is some kind of=20 > mainframe OS. >=20 > What happens is this: >=20 > client: initiates connections, 3way handshake completes > server: closes connection (FIN) > client: (at the same moment) sends data to server > server: RST > client: argh (reports EIO to application) >=20 > What seems to happen here is the random connection drop in=20 > svcsock.c, where we randomly drop a connection if the total=20 > number of TCP connections exceeds (nrthreads + 3) * 10. =20 > "Randomly" here means either the oldest connection, or the=20 > newest one (which happens to be the one we just accepted). >=20 > The specific problem we have here is that the client doesn't=20 > grok TCP RSTs generated by the server. It's arguably a client=20 > bug, but I'm nevertheless thinking about a way to work around this >=20 > Possible solutions: >=20 > - always drop the oldest connection. The current strategy doesn't > help much against DoS anyway, because rather than dropping > old connections for _every_ new one, we drop them for every > two new connections. Big improvement :) >=20 > - Create a sysctl that allows to set a hard limit for active > TCP connections. >=20 > - increase the "random drop" threshold to something like > (nrthreads + 3) * 100. >=20 > Any comments? >=20 > Olaf > --=20 > Olaf Kirch | Stop wasting entropy - start using predictable > okir@suse.de | tempfile names today! > ---------------+=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President=20 > and CEO of GenToo technologies. Learn everything from=20 > fundamentals to system=20 > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > NFS maillist - NFS@lists.sourceforge.net=20 > https://lists.sourceforge.net/lists/listinfo/n> fs >=20 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs