Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

When I cksum large files (150MB) they will often report different checksums on each call.

$ cksum test3
1233504235 170213376 test3
$ cksum test3
825031809 170213376 test3
$ cksum test3
189847968 170213376 test3
$ cksum test3
1089532177 170213376 test3

This happens consistently in /dev/shm but I've seen it in disk based ext3 filesystems as well.

I am confident the files are not being written to at the time of the checks.

It's been an issue since I upgraded from Debian 6 32bit to 7 32bit but I had similar issues on 64bit Debian 6 (reinstalled 32bit to cure the problem).

The memory has passed multiple Memtest86+ runs. The are no indications of filesystem corruption.

Could there be a BIOS setting; kernel parameter or filesystem flag that I need to set.

filesystem flags are:

tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=2040740k)
/dev/disk/by-uuid/b236be25-6fe1-49f6-83a3-d295643666a4 on / type ext3 (rw,relatime,errors=remount-ro,barrier=1,data=ordered)

This is driving me nuts as my data files keep getting corrupted and I can't use the system.

UPDATE

Booting off the previous kernel (2.6.32) stops the file corruptions. It also reduces the memory from 4GB to 3GB even tho both kernels report 'getconf LONG_BIT' as 32

share|improve this question

migrated from serverfault.com Sep 4 '13 at 14:10

This question came from our site for professional system and network administrators.

1  
Curious, what do you get with md5? –  KM. Sep 4 '13 at 0:21
    
Can you create a dummy file in the same folder that exhibits the same behaviour? What is your kernel version? Have you tried mounting the disk on a different system? –  Andrew Sep 4 '13 at 2:27
    
I do get the same problem when using md5sum. –  Dave Billington Sep 4 '13 at 7:36
    
Kernel is SMP Debian 3.2.46-1+deb7u1. I haven't tried moving the disk but /dev/shm is created in memory after each reboot and reboots do not resolve the problem. –  Dave Billington Sep 4 '13 at 7:42
    
Any large file in /dev/shm exhibits the same behaviour. I've tried several different file types. –  Dave Billington Sep 4 '13 at 7:46
show 3 more comments

1 Answer 1

I suggest inspecting the file itself and seeing if it is actually valid and consistent.

cksum computes a CRC. There is a purpose-specific instruction for this on modern x86 CPUs which may or may not be in use here; in that case it is possible that the CPU might be faulty, and also possible that this fault might not show up anywhere else. Consider ensuring your microcode is up to date or trying to checksum the file using another utility that doesn't do CRC (md5sum comes to mind), or testing this on another computer.

share|improve this answer
    
I do have a validator for the file structure and that also shows the problem. However I thought using cksum for my examples would be better. It might be a CPU fault but md5sum also shows the same problem as does sum. I have tested this on another Debian 7 system and I do not get this issue. –  Dave Billington Sep 4 '13 at 7:54
    
It is most likely some kind of obscure hardware or firmware issue. –  Falcon Momot Sep 4 '13 at 8:16
    
I've updated the firmware to the latest version but this has made no difference. –  Dave Billington Sep 4 '13 at 9:10
1  
Well, you likely have your answer then. –  Falcon Momot Sep 4 '13 at 9:19
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.