xfs
[Top] [All Lists]

[Bug 198] file corruption over NFSv3 UDP using 1.2pre3

To: xfs-master@xxxxxxxxxxx
Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3
From: bugzilla-daemon@xxxxxxxxxxx
Date: Mon, 18 Nov 2002 10:07:58 -0800
Sender: linux-xfs-bounce@xxxxxxxxxxx
http://oss.sgi.com/bugzilla/show_bug.cgi?id=198





------- Additional Comments From cattelan@xxxxxxxxxxx  2002-11-18 09:35 -------
Subject: Re:  New: file corruption over NFSv3 UDP using 1.2pre3

Hmmm this does not look good.
I would be helpful to see exactly what went wrong in the file.
A cmp -l might be a good start or a hexdump -v on both the good and the
bad files and them diffing the output.
Basically what we are looking for is what "bad" data ended up in the
file and start position and length of the bad data.

On Mon, 2002-11-18 at 11:03, bugzilla-daemon@xxxxxxxxxxx wrote:
> http://oss.sgi.com/bugzilla/show_bug.cgi?id=198
> 
>            Summary: file corruption over NFSv3 UDP using 1.2pre3
>            Product: Linux XFS
>            Version: 1.2.x
>           Platform: IA32
>         OS/Version: Linux
>             Status: NEW
>           Severity: critical
>           Priority: High
>          Component: XFS kernel code
>         AssignedTo: xfs-master@xxxxxxxxxxx
>         ReportedBy: stephy32@xxxxxxxxxxxx
> 
> 
> If this is a userspace bug, what version of the package are you using:
> 
> What kernel are you using: 
> 2.4.18-17SGI_XFS1.2pre3 and 2.4.19-SGI_XFS1.2pre3
> 
> Where did the XFS code come from?  (CVS, Linus, your distribution, etc):
> Downloaded the kernel source RPM from sgi web site.
> 
> Description of Problem:
>       Using Dell Poweredge 4600 server and exporting the second system drive, 
> file
> integrity verification fails.  The failure occure on linux RH 7.3 clients,  O2
> with IRIX and Sun Netra5.  The server is using Intel E1000 PCI-X (2X) with or
> without bonding.
> 
> The test is ran concurently on 5 clients over gigabit ethernet or 100BT.
> The test is perform by creating a 3 Gigabyte file on the client using local
> storage.  The file is then copied onto the NFS mount point and then copied 
> back
> under a different name.  Then the original file is compared with both file, 
> the
> one on the NFS server and the copy locally.  Within 3 to 4 hours of running 
> the
> test so after 10 to 20 sucessful pass, the test fails.
> 
> 
> How Reproducible:
>       All the time, nothing reported by enabling CONFIG_XFS_DEBUG,
> CONFIG_PAGEBUF_DEBUG, CONFIG_KERNEL_ASSERT.  Tested with max_cpus=1 also.
> 
> Steps to Reproduce:
> 1.  Mount the server over NFS with rsize=8192,wsize=8192,hard,udp under /ts1
> 2.  Create a local test file: dd if=/dev/random of=/var/tmp/test bs=1024k
> count=3000
> 3.  Copy the file over to the server: cp /var/tmp/test /ts1/test-`hostname`
> 4. Copy the file back: cp /ts1/test-`hostname` /var/tmp/test-`hostname`.BACK
> 5. compare the files and their csum:
> 
> Actual Results:
>       A difference between the original file and the file over NFS
> 
> Expected Results:
>       No differences, please.
> 
> Additional Information:
>       Running the same test with RH kernel without XFS using EXt2 din't fails 
> after
> 30HRS.
>       The internal SCSI is AIX7900.
> 
> .config file changes:  SCSI and AIC7XXX built in instead of as module.  Tested
> also with Hardware Raid 5 over Fiber Channel, it just takes longer to hit the
> Bug.
> 
> email me if you need more info.
> 
> Stephane Harnois
> 
> 
> 
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> 




------- Additional Comments From cattelan@xxxxxxxxxxx  2002-11-18 10:07 -------
Hmmm this does not look good.
I would be helpful to see exactly what went wrong in the file.
A cmp -l might be a good start or a hexdump -v on both the good and the
bad files and them diffing the output.
Basically what we are looking for is what "bad" data ended up in the
file and start position and length of the bad data.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


<Prev in Thread] Current Thread [Next in Thread>