当我对大文件（150MB）进行 cksum 时，它们通常会在每次调用时报告不同的校验和。
$ cksum test3
1233504235 170213376 test3
$ cksum test3
825031809 170213376 test3
$ cksum test3
189847968 170213376 test3
$ cksum test3
1089532177 170213376 test3
这种情况持续发生在/dev/shm但我也在基于磁盘的 ext3 文件系统中看到过它。
我确信这些文件是不是在检查时写入。
自从我从 Debian 6 32 位升级到 7 32 位以来，这一直是一个问题，但我在 64 位 Debian 6 上也遇到了类似的问题（重新安装 32 位以解决问题）。
内存已通过多次 Memtest86+ 运行。没有迹象表明文件系统已损坏。
是否有BIOS设置；我需要设置的内核参数或文件系统标志。
文件系统标志是：
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)
这让我抓狂，因为我的数据文件不断损坏，而且我无法使用该系统。
更新
从以前的内核 (2.6.32) 启动可以阻止文件损坏。它还将内存从 4GB 减少到 3GB，即使两个内核都将“getconf LONG_BIT”报告为 32
答案1
我建议检查文件本身，看看它是否确实有效且一致。
cksum计算 CRC。现代 x86 CPU 上有一条专用指令，可能在这里使用，也可能没有；在这种情况下，CPU 可能有故障，也可能这个故障不会出现在其他地方。请考虑确保您的微代码是最新的，或者尝试使用另一个不执行 CRC 的实用程序（md5sum想到了）对文件进行校验和，或者在另一台计算机上测试它。
答案2
下面的文件/dev比较特殊。特别是，/dev/shm是共享内存内容的安装点，请参阅shm_overview(7)。难怪它会“在你背后”发生变化。制作当然您神秘地更改的文件不是某种数据库或随正常操作而更改的其他内容。