From wefa@unicom.talkline.de  Wed Sep 10 11:24:31 1997
Received: from thetis.Talkline.DE (root@thetis.talkline.de [194.195.171.2])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA17901
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 10 Sep 1997 11:24:25 -0700 (PDT)
Received: from ohura.talkline.de by thetis.Talkline.DE with smtp
	(Smail3.1.29.1 #3) id m0x8qgd-0006qhC; Wed, 10 Sep 97 19:36 MET DST
Received: from MailHost.Talkline.DE [172.16.1.16] (root)
	by ohura.talkline.de with smtp (Exim 1.61 #1)
	id 0x8qPx-0007x3-00; Wed, 10 Sep 1997 19:19:05 +0200
Received: from helena.unicom.de by MailHost.Talkline.DE with smtp
	(Smail3.1.29.1 #3) id m0x8rNy-000QmrC; Wed, 10 Sep 97 19:21 GMT+0100
Received: (from wefa@localhost) 
    by helena.unicom.de (8.8.5/8.6.12 unicom) id UAA04192; 
    :Wed, 10 Sep 1997 20:23:59 +0200 (MET DST)
Message-Id: <199709101823.UAA04192@helena.unicom.de>
Date: Wed, 10 Sep 1997 20:23:59 +0200 (MET DST)
From: Christoph Weber-Fahr <wefa@unicom.talkline.de>
Reply-To: wefa@unicom.talkline.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: nfs3 data integrity problems
X-Send-Pr-Version: 3.2

>Number:         4508
>Category:       kern
>Synopsis:       nfs3 data integrity problems
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    peter
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 10 11:30:01 PDT 1997
>Closed-Date:    Sat Dec 11 23:55:36 PST 1999
>Last-Modified:  Sat Dec 11 23:56:31 PST 1999
>Originator:     Christoph Weber-Fahr
>Release:        FreeBSD 2.2.2-RELEASE i386
>Organization:
O.tel.o Communications
>Environment:

	two FreeBSD 2.2.2-RELEASE machines.
	- P90/32MB/3C590/AHA2940
	- 486DX2-66i/16MB/NE2000 Clone/AHA1542B

>Description:

	Machine 2 acts as "code server", i.e. it has the complete source
 	tree and nfs-exports it to various other machines, among them #1.
	Machine 1 tries to compile a kernel for a third machine.
	in 90% of the attempts compilation falls over various
        errors in vnode_if.c . vnode_if.c is generated by a shell script
 	in the make depend step. When examining vnode_if.c one notices
	a large block of zero bytes (0x00) within the file.
	Every Test involved at least a complete "make clean;make depend;make"
	cycle.
	The problem goes away, when
	- one removes vnode_if.c and restarts make (it is newly generated
	  by the make process)
	- one compiles the kernel locally on machine 2 (doing the make depend
	  step there is sufficient)
	- one forces nfs2 mount between the machines.

	The abovementioned problem is the most often boserved one.
	I also got sucessful compiles and unexplainable link fails and
	similar effects.

	My suspicion is that in certain stress situations nfs writes 
	are not correctly transmitted. The problem occurs with both TCP
	and UDP mounts so I tend not to blame underlying protocols.
	

>How-To-Repeat:

	use the abovementioned (or similar) system combo.
	mount /usr/src from system 2 on /usr/src on system 1
	Generate a kernel according to the appended kernel file
	on system 1 in the nfs-mounted kernel compile directory.
	
#
# REM: minimal kernel for a small simple 386sx machine with 5 Megs
#

machine		"i386"
cpu		"I386_CPU"
ident		REM
maxusers	5

options		GPL_MATH_EMULATE
options		INET
options		FFS
options		PROCFS
options		"COMPAT_43"
options		FAILSAFE

config		kernel	root on wd0

controller	isa0

controller	wdc0	at isa? port "IO_WD1" bio irq 14 vector wdintr
disk		wd0	at wdc0 drive 0

device		sc0	at isa? port "IO_KBD" tty irq 1 vector scintr

device		npx0	at isa? port "IO_NPX" flags 0x1 irq 13 vector npxintr

device		sio0	at isa? port "IO_COM1" tty irq 4 vector siointr
device		sio1	at isa? port "IO_COM2" tty irq 3 vector siointr

device		lpt0	at isa? port? tty irq 7 vector lptintr

device ep0 at isa? port 0x300 net irq 10 vector epintr

pseudo-device	loop
pseudo-device	ether
pseudo-device	log
pseudo-device	tun	1
pseudo-device	pty	8


>Fix:

	none.
	Workaround: use nfs2
	

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->peter 
Responsible-Changed-By: peter 
Responsible-Changed-When: Sun Apr 26 00:44:53 PDT 1998 
Responsible-Changed-Why:  
I'll take this one.. 

From: Greg Snyder <gregs@iprg.nokia.com>
To: freebsd-gnats-submit@freebsd.org, wefa@unicom.talkline.de
Cc: jre@iprg.nokia.com, gregs@iprg.nokia.com
Subject: Re: kern/4508: nfs3 data integrity problems
Date: Mon, 15 Jun 1998 17:01:30 -0700

 We are experiencing this exact same problem on 2.2.6-RELEASE.
 It appears that the writes are going through, as the file server (in
 this case a netapp filer) has the correct version of the file.  This can
 be verified from a different machine.   Looking at vnode_if.c, the
 problem bytes start exactly on the last page boundary (12k in, in this
 case).  Most of the rest of the file after this page boundary is NULs.
 This file is available if you want it.  The problem only showed up on
 NFSv3.
 
 	Any ideas on this?
 
 Thanks,
 Greg Snyder, Nokia IPRG
State-Changed-From-To: open->closed 
State-Changed-By: dillon 
State-Changed-When: Sat Dec 11 23:55:36 PST 1999 
State-Changed-Why:  
Many NFS bugs related to bogus zerod out areas in files have been fixed 
in 3.x and 4.x.  A few of these fixes have been backported to 2.2.x but 
if you are using NFS heavily I would recommend upgrading. 
>Unformatted:
