From owner-freebsd-fs@FreeBSD.ORG Fri Oct 14 19:55:01 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 65AF916A41F for ; Fri, 14 Oct 2005 19:55:01 +0000 (GMT) (envelope-from cel@citi.umich.edu) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id F141343D46 for ; Fri, 14 Oct 2005 19:55:00 +0000 (GMT) (envelope-from cel@citi.umich.edu) Received: from [10.58.52.227] (nat-198-95-226-230.netapp.com [198.95.226.230]) by citi.umich.edu (Postfix) with ESMTP id 0FCDC1BBDC; Fri, 14 Oct 2005 15:54:59 -0400 (EDT) Message-ID: <43500D13.1030702@citi.umich.edu> Date: Fri, 14 Oct 2005 15:54:59 -0400 From: Chuck Lever Organization: Network Appliance, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rick@snowhite.cis.uoguelph.ca References: <200510141742.NAA23853@snowhite.cis.uoguelph.ca> In-Reply-To: <200510141742.NAA23853@snowhite.cis.uoguelph.ca> Content-Type: multipart/mixed; boundary="------------070508070106000201080603" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: fs@freebsd.org 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 Reply-To: cel@citi.umich.edu List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2005 19:55:01 -0000 This is a multi-part message in MIME format. --------------070508070106000201080603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit rick@snowhite.cis.uoguelph.ca wrote: >>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, where is that rule stated? most NFS clients i am aware of retransmit an RPC after 60 seconds over TCP. > but that should be fixed for NFSv4. agreed. >> 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. that assumes the client uses a threaded implementation too, doesn't it? --------------070508070106000201080603--