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.


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

  • 2
    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

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.

  • 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

The files under /dev are special. In particular, /dev/shm is the mountpoint for shared memory stuff, see shm_overview(7). No wonder it changes "behind your back". Make sure your mysteriously changing files aren't e.g. a database of some sort or something else that changes with normal operations.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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