From owner-freebsd-current@FreeBSD.ORG Wed Mar 26 02:21:26 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8C1937B404 for ; Wed, 26 Mar 2003 02:21:26 -0800 (PST) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id BD8E743F85 for ; Wed, 26 Mar 2003 02:21:25 -0800 (PST) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Mar 2003 10:21:25 +0000 (GMT) To: Terry Lambert In-Reply-To: Your message of "Tue, 25 Mar 2003 18:52:59 PST." <3E81160B.E5406C60@mindspring.com> Date: Wed, 26 Mar 2003 10:21:21 +0000 From: Ian Dowse Message-ID: <200303261021.aa90692@salmon.maths.tcd.ie> X-Spam-Status: No, hits=-14.7 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: current@freebsd.org Subject: Re: NFS -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 10:21:30 -0000 In message <3E81160B.E5406C60@mindspring.com>, Terry Lambert writes: >Ian Dowse wrote: >> It is normal enough to get the above 'not responding' errors >> occasionally on a busy fileserver, but only if they are almost >> immediately followed by 'is alive again' messages. > >This is arguably a bug in the FreeBSD UDP packet reassembly code ... Actually, I was referring here to an effect that occurs when the time taken by the server to complete requests varies in a particular way. The NFS client may observe a large number of requests all answered within a few milliseconds, so it starts using short timeouts. Then for some reason (usually a long list of outstanding disk-intensive operations), the server takes a few seconds to complete the next request. Within this time, the client repeatedly times out, retransmits the request, backs off and repeats, and in extreme cases it is possible for the client to reach the limit that triggers the "not responding" warning. Ian