From owner-freebsd-fs@FreeBSD.ORG Fri Oct 14 17:52:52 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 F3D6816A41F for ; Fri, 14 Oct 2005 17:52:51 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28AF043D69 for ; Fri, 14 Oct 2005 17:52:47 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j9EHqkZT092134 for ; Fri, 14 Oct 2005 12:52:46 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <434FF058.1010800@centtech.com> Date: Fri, 14 Oct 2005 12:52:24 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-us, en MIME-Version: 1.0 To: fs@freebsd.org References: <200510141750.NAA24051@snowhite.cis.uoguelph.ca> In-Reply-To: <200510141750.NAA24051@snowhite.cis.uoguelph.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1134/Fri Oct 14 03:07:44 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: Subject: Re: 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:52:52 -0000 rick@snowhite.cis.uoguelph.ca wrote: > [good stuff snipped] > >>threads), but they wait until the disks are not busy. I'm not really >>sure what it would give you to have the nfsd's wait until disk is not as >>busy, as that is what it is doing now, right? Maybe you would smooth > > > The difference is that, if the nfsd threads don't take the request off > the socket receive queue, then the TCP send window slows/stops new > requests being sent from the client at some point. > > Currently, the nfsd thread takes the request off the TCP sockets receive > queue and then sleeps inside the VFS/VnodeOp calls. > (As noted in the previous email, I think what happens now is good enough > for most cases, so long as the client doesn't retry the RPCs. I had > forgotten that the TCP seq# would cause TCP level retransmits to be > discarded, even after the request is removed from the receive queue.) Then what happens when the socket receive queue fills up? (Sorry if this is obvious). Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------