From owner-freebsd-stable Mon Dec 17 12:45:14 2001 Delivered-To: freebsd-stable@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 2674137B41C; Mon, 17 Dec 2001 12:45:07 -0800 (PST) Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 17 Dec 2001 20:45:05 +0000 (GMT) To: "Marius M. Rex" Cc: questions@FreeBSD.org, stable@FreeBSD.org Subject: Re: on/off NFS connection errors In-Reply-To: Your message of "Mon, 17 Dec 2001 13:59:23 EST." <20011217120545.D48149-100000@malkav.snowmoon.com> Date: Mon, 17 Dec 2001 20:45:05 +0000 From: Ian Dowse Message-ID: <200112172045.aa49374@salmon.maths.tcd.ie> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20011217120545.D48149-100000@malkav.snowmoon.com>, "Marius M. Rex" writes: > >><118>Dec 15 22:40:19 cc117 /kernel: nfs server netapp1:/vol/members: not >>responding >><118>Dec 15 22:40:19 cc117 /kernel: nfs server netapp1:/vol/members: is >>alive again ... >Has anyone else seen these kinds of persistent NFS errors is the 4.x >branch? These are a side-effect of the operation of the NFS dynamic retransmit timeout code. The NFS client measures the request response time for various types of operations and it sets a timeout based on the mean and deviation of observed times. The time taken by the server to perform some operations can vary wildly though, so occasionally when a large number of operations complete with very little delay, the response time estimate and hence the timeout become very small. Then when one request is unusually slow to complete (such as when the disk on the server is busy), the client thinks that the server isn't responding and prints those warnings. A fraction of a second later the request completes and the client prints a an 'is alive again' message. On non-soft mounts these messages are completely harmless because the client will just wait for the server to eventually reply. On soft mounts, the effect can cause problems because applications occasionally see an EINTR error. The dynamic retransmit timeout code can be disabled with the `-d' flag to mount_nfs; this is often recommended for fast networks that see very little packet loss. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message