Bug 157904 - Content of large files change on every read
Content of large files change on every read
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-16 18:11 EDT by Richard Körber
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-17 13:46:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Körber 2005-05-16 18:11:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de-AT; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1

Description of problem:
I am working with rather large files (about 3 GB). If I do a "md5sum -b $largefile", I will always get different sums, but the file itself is unchanged!

The same happens if I copy a large file, and then make a diff. The file should be identical, but diff says it isn't.

Version-Release number of selected component (if applicable):
2.6.11-1.14_FC3

How reproducible:
Always

Steps to Reproduce:
1. Create a large file (about 3 GB)
2. Repeatedly do a "md5sum -b $largefile" on that file
  

Actual Results:  Most often, different md5 sums are returned even though the file is unchanged.

Expected Results:  Always getting the same md5 sum because the file did not change.

Additional info:

My hardware: AMD Athlon64 3000+, Asus K8V SE Deluxe mainboard, 1x PATA hard disk, 2x SATA hard disks (Software RAID-0). Latest Asus BIOS is installed. The system is not overclocked. The RAM has been successfully tested using memtest86 for more than 10 hours. The partitions are EXT3 formatted.

First I suspected the on-board VIA SATA RAID controller, so I connected the hard disks to the on-board Promise SATA RAID controller. The issue remained reproducable though.

I copied the large file to a PATA hard disk. Even there, md5sum always gave different sums.

I went back to the original FC3 kernel (2.6.9-1.667) but it didn't help either. The bug was also reproducable in an "init 1" environment, though then I got a few consecutively correct md5sums.

When booting from the FC3 rescue CD, everything seems to be fine.
Comment 1 Richard Körber 2005-05-17 13:46:51 EDT
Actually, it turned out to be a mainboard issue!

If there is double sided RAM in slot 0 and 1, and Cool&Quiet is enabled, the
data read from IDE or SATA will be corrupted.

I have moved the second RAM bar from slot 1 to slot 2, and now everything is
working fine again.

Resolved to WorksForMe, since this is not a Linux issue. I'm sorry!

Note You need to log in before you can comment on or make changes to this bug.