Red Hat Bugzilla – Bug 157904
Content of large files change on every read
Last modified: 2007-11-30 17:11:06 EST
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):
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.
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.
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!