From owner-freebsd-bugs@FreeBSD.ORG Wed Mar 17 06:40:22 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 455B816A4CE for ; Wed, 17 Mar 2004 06:40:22 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E12243D2D for ; Wed, 17 Mar 2004 06:40:22 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) i2HEeMbv002630 for ; Wed, 17 Mar 2004 06:40:22 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2HEeMNf002629; Wed, 17 Mar 2004 06:40:22 -0800 (PST) (envelope-from gnats) Date: Wed, 17 Mar 2004 06:40:22 -0800 (PST) Message-Id: <200403171440.i2HEeMNf002629@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Stephen McKay Subject: Re: kern/64091: nfs data corruption at end of file X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Stephen McKay List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 14:40:22 -0000 The following reply was made to PR kern/64091; it has been noted by GNATS. From: Stephen McKay To: freebsd-gnats-submit@FreeBSD.org, nils@shkoo.com Cc: Stephen McKay Subject: Re: kern/64091: nfs data corruption at end of file Date: Thu, 18 Mar 2004 00:39:37 +1000 I can confirm this bug. With a server running 4.9-RELEASE and client running 4.8-RELEASE-p13 the test ran for a few minutes before it failed. With a server running 4.9-RELEASE and client running 5.2.1-RELEASE the test also fails, sometimes after only a few seconds. I also ran /usr/src/tools/regression/fsx with the 4.9-RELEASE server and 5.2.1-RELEASE client. This failed after about half an hour. I have the log file from this if it is of any use to anybody. This is not all just theoretical either. I have had a failure due to a file growing on the server and being incorrectly read on the client. After I had freshly installed 5.2.1, I started downloading packages onto the file server. Sometimes I accidentally attempted to install a partially downloaded package. The checksum prevented this, of course. However, as a side effect, this caused one of the package files to be permanently mis-cached on the 5.2.1 client (it has 1GB of RAM, so flushing all that cache was too hard). The file (from the client end) appeared to be normal up to a point, then nothing but zeroes from then on. The cutoff point in this case was at 28672 bytes, a multiple of 4096 but not a block boundary on this file system. Stephen.