Date: Fri, 14 Oct 2005 15:54:59 -0400 From: Chuck Lever <cel@citi.umich.edu> To: rick@snowhite.cis.uoguelph.ca Cc: fs@freebsd.org Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients Message-ID: <43500D13.1030702@citi.umich.edu> In-Reply-To: <200510141742.NAA23853@snowhite.cis.uoguelph.ca> References: <200510141742.NAA23853@snowhite.cis.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43500D13.1030702>