From owner-freebsd-fs@FreeBSD.ORG Fri Oct 14 17:41:37 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8733C16A44E for ; Fri, 14 Oct 2005 17:41:37 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from dargo.cs.uoguelph.ca (dargo.cs.uoguelph.ca [131.104.96.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3199043D45 for ; Fri, 14 Oct 2005 17:41:36 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by dargo.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id j9EHfYeU013258 for ; Fri, 14 Oct 2005 13:41:36 -0400 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id NAA23853 for fs@freebsd.org; Fri, 14 Oct 2005 13:42:58 -0400 (EDT) Date: Fri, 14 Oct 2005 13:42:58 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca Message-Id: <200510141742.NAA23853@snowhite.cis.uoguelph.ca> To: fs@freebsd.org X-Scanned-By: MIMEDefang 2.52 on 131.104.96.159 Cc: Subject: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 17:41:37 -0000 > Tcp always throws away retransmissions. Doesn't matter whether the data is > still in the receive socket queue or not. The nfs server will never see > replayed requests as a result of tcp retransmission. 1) Yes, of course. (Brain fart on my part. I mentioned I wasn't a TCP wizzard, didn't I?:-) There is still the problem that not all clients obey the "only retry an RPC after a disconnect/reconnect" rule, but that should be fixed for NFSv4. > The problem is "how do you make sure the nfsd threads don't start a > request if the disk I/O subsystem is backlogged". > > Isn't this simply a matter of choosing the right number of nfsd threads? That's the only mechanism available to-day (at least for my server and, I think, the current FreeBSD one). Unfortunately load is pretty dynamic and it might be nice if "the number of active nfsd threads" changed to reflect that, without manual sysadmin intervention. However, given 1) and clients that only retry RPCs after a reconnect, I don't think it will be all that critical. The clients will see the slow response to RPCs and new requests will be limited by the number of threads doing I/O on the client. Other opinions? rick