Date: Wed, 17 Mar 2004 06:40:22 -0800 (PST) From: Stephen McKay <smckay@internode.on.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/64091: nfs data corruption at end of file Message-ID: <200403171440.i2HEeMNf002629@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/64091; it has been noted by GNATS. From: Stephen McKay <smckay@internode.on.net> To: freebsd-gnats-submit@FreeBSD.org, nils@shkoo.com Cc: Stephen McKay <smckay@internode.on.net> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403171440.i2HEeMNf002629>