From nobody@FreeBSD.org  Thu Mar 11 01:00:43 2004
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 521F816A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 11 Mar 2004 01:00:43 -0800 (PST)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4948343D48
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 11 Mar 2004 01:00:43 -0800 (PST)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.10/8.12.10) with ESMTP id i2B90h72052166
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 11 Mar 2004 01:00:43 -0800 (PST)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.10/8.12.10/Submit) id i2B90hFR052165;
	Thu, 11 Mar 2004 01:00:43 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200403110900.i2B90hFR052165@www.freebsd.org>
Date: Thu, 11 Mar 2004 01:00:43 -0800 (PST)
From: nils mccarthy <nils@shkoo.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: nfs data corruption at end of file
X-Send-Pr-Version: www-2.3

>Number:         64091
>Category:       kern
>Synopsis:       [nfs] nfs data corruption at end of file
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    peadar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 11 01:10:12 PST 2004
>Closed-Date:    Sat Mar 04 09:59:22 GMT 2006
>Last-Modified:  Sat Mar 04 09:59:22 GMT 2006
>Originator:     nils mccarthy
>Release:        5.2.1-RELEASE
>Organization:
>Environment:
FreeBSD fbsd5.whatzit.org 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004     root@wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
Running tail -f or equivalent on nfs-mounted file that grows will occasionally result in corrupted data being returned.  Specifically, NUL characters will show up.

(problem also exists in 4.8-RELEASE)
>How-To-Repeat:
Download and compile readtest and writetest from http://www.llnw.com/fbsd-nfs-bug/.

Run writetest on NFS server and readtest on NFS client, both in the same directory.

After a while (under 5 minutes on my system), readtest will report that it received a bogus character that was not part of the pattern that writetest was writing.

>Fix:
      
>Release-Note:
>Audit-Trail:

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.
State-Changed-From-To: open->patched 
State-Changed-By: peadar 
State-Changed-When: Wed Apr 14 16:25:21 PDT 2004 
State-Changed-Why:  
Patch committed to -current. 



Responsible-Changed-From-To: freebsd-bugs->peadar 
Responsible-Changed-By: peadar 
Responsible-Changed-When: Wed Apr 14 16:25:21 PDT 2004 
Responsible-Changed-Why:  
My patch, so the problems are mine. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=64091 

From: Matteo Riondato <rionda@gufi.org>
To: Gnats PR Database <freebsd-gnats-submit@freebsd.org>
Cc: peadar@freebsd.org
Subject: Re: kern/64091: [nfs] nfs data corruption at end of file
Date: Sat, 9 Apr 2005 19:58:31 +0200

 --McOwgVabxjWRBDh+
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 This was fixed in RELENG_5 too. Don't know about RELENG_4. If the
 merge isn't needed/possible, this PR can be closed.
 Thank you
 Best Regards
 --=20
 Rionda aka Matteo Riondato
 Disinformato per default
 G.U.F.I. Staff Member (http://www.gufi.org)
 FreeSBIE Developer (http://www.freesbie.org)
 
 --McOwgVabxjWRBDh+
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.0 (FreeBSD)
 
 iD8DBQFCWBfH2Mp4pR7Fa+wRApNVAKCDubawdHJjxRjwtnwqQri6uSuTzACfURgy
 adQJQFeMkUGw3D3ppkRdFj0=
 =1HNM
 -----END PGP SIGNATURE-----
 
 --McOwgVabxjWRBDh+--
State-Changed-From-To: patched->closed 
State-Changed-By: matteo 
State-Changed-When: Sat Mar 4 09:58:42 UTC 2006 
State-Changed-Why:  
Some time ago I noticed this was fixed in  RELENG_5 too, so we can close this 

http://www.freebsd.org/cgi/query-pr.cgi?pr=64091 
>Unformatted:

Here's an exerpt of a private mail analysing the problem:

> 
> If the file changes on the server, the client normally invalidates
> its cached copy because the modification date changes (the server
> can even report this to the client in responses to read requests,
> etc). However, the server can always end up changing the size twice
> within the modification time's resolution. As a result, the attributes
> of the file reflect the new size, but the cache is never invalidated.
> 
> When this happens, and you try to read the end of the file, the
> client has what it thinks is a valid cached block, but the block
> was read before the file was extended.  The end result is you get
> the zero padding at the end of the block.

The patch committed to sys/nfsclient in -current  fixes the issue
by noticing the change in a file's size, and flagging it in nfsnode's
n_flag attribute.  This is later used along with the modification
timestamp to decide if the local data is stale.
