simmcrd提出的问题 -ubuntu

simmcrd

Asked: 2019-07-25 12:47:31 +0800 CST

18.04 LTS 上的文件损坏大文件 (32 GB) [已解决]

我收到大文件的违规行为。我有 64 GB 的 RAM，我的存储驱动器都是三星 860 EVO。我在原始驱动器上运行 mdcrypt，在其上运行 luks RAID，并将 ext4 作为文件系统。我有很多可用的驱动器空间，并且没有运行交换。

我的发行版是 Ubuntu 18.04 LTS（4.18.0-25-generic #26~18.04.1-Ubuntu SMP Thu Jun 27 07:28:31 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux）。

这种不规则性是在克隆大型 USB 拇指驱动器时首次发现的。然后我注意到大型循环挂载文件系统也会损坏。

片段如下：

我通过创建一个 32 GB 的零文件开始我的测试：

$ dd if=/dev/zero of=zero-file_32GB bs=1024k count=32768
32768+0 records in
32768+0 records out
34359738368 bytes (34 GB, 32 GiB) copied, 55.3081 s, 621 MB/s

然后我 SHA256 对该文件求和以获得哈希码。请注意哈希如何随着多次迭代而变化：

$ sha256sum zero-file_32GB 
5f7f8ea75d87ac7d64c07ecc2c5fdbe407540913ac0feb050ede768990140b38  zero-file_32GB

$ sha256sum zero-file_32GB 
64bcf7372df895319ce9e54758aec2814600fa3335fb82c5996a7636e7d637be  zero-file_32GB

$ sha256sum zero-file_32GB 
3475353b2a00e5abebb1878a9ddb5956eb829c94af26d9cd079f991fbd84435c  zero-file_32GB

$ sha256sum zero-file_32GB 
cf65fa70ba04d7bb4055b72fdf2ac90bf65ac8457cc80b8e673af5acb57d22d1  zero-file_32GB

MD5 sum 也会出现同样的不一致：

$ md5sum zero-file_32GB 
8633b9ba83a8ac04c9b56fad0a065ec2  zero-file_32GB

$ md5sum zero-file_32GB 
cc289d380b25235b7610a7b86bc4fd47  zero-file_32GB

$ md5sum zero-file_32GB 
249f66bd3843b6fcad8316fd0a3e660c  zero-file_32GB

$ md5sum zero-file_32GB 
888ac00592204be7a026c27e98159ff2  zero-file_32GB

到目前为止，我相当有信心我的文件已损坏，而不是哈希求和算法。为了验证这个假设，我将我的 32 GB 零文件拆分为 32 个 1 GB 块：

$ split --verbose -b 1G zero-file_32GB split-1G_
creating file 'split-1G_aa'
creating file 'split-1G_ab'
creating file 'split-1G_ac'
creating file 'split-1G_ad'
creating file 'split-1G_ae'
creating file 'split-1G_af'
creating file 'split-1G_ag'
creating file 'split-1G_ah'
creating file 'split-1G_ai'
creating file 'split-1G_aj'
creating file 'split-1G_ak'
creating file 'split-1G_al'
creating file 'split-1G_am'
creating file 'split-1G_an'
creating file 'split-1G_ao'
creating file 'split-1G_ap'
creating file 'split-1G_aq'
creating file 'split-1G_ar'
creating file 'split-1G_as'
creating file 'split-1G_at'
creating file 'split-1G_au'
creating file 'split-1G_av'
creating file 'split-1G_aw'
creating file 'split-1G_ax'
creating file 'split-1G_ay'
creating file 'split-1G_az'
creating file 'split-1G_ba'
creating file 'split-1G_bb'
creating file 'split-1G_bc'
creating file 'split-1G_bd'
creating file 'split-1G_be'
creating file 'split-1G_bf'

然后我对新文件拆分进行 SHA256 求和。它们都应该是相同的，因为它们每个都应该只包含零。但请注意拆分az和ba的不一致：

$ sha256sum split-1G_??                                                                                                                                                  
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_aa                                                                                                                        
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ab                                                                                                                        
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ac                                                                                                                        
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ad                                                                                                                        
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ae                                                                                                                        
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_af                                                                                                                        
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ag                                                                                                                        
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ah                                                                                                                        
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ai                                                                                                                        
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_aj
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ak
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_al
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_am
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_an
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ao
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ap
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_aq
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ar
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_as
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_at
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_au
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_av
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_aw
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ax
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_ay
702301f26e8df8cf784ca6b45954f1ca3524d1e22c322ee271ab1ac20b4face2  split-1G_az
bd9442046cecfcdec29169f5e8485ee0e226f56fab24cfded23b4ad15275b5d9  split-1G_ba
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_bb
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_bc
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_bd
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_be
49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  split-1G_bf

与 MD5 和的类似不一致：

$ md5sum split-1G_??   
cd573cfaace07e7949bc0c46028904ff  split-1G_aa
cd573cfaace07e7949bc0c46028904ff  split-1G_ab
cd573cfaace07e7949bc0c46028904ff  split-1G_ac
cd573cfaace07e7949bc0c46028904ff  split-1G_ad
cd573cfaace07e7949bc0c46028904ff  split-1G_ae
cd573cfaace07e7949bc0c46028904ff  split-1G_af
cd573cfaace07e7949bc0c46028904ff  split-1G_ag
cd573cfaace07e7949bc0c46028904ff  split-1G_ah
cd573cfaace07e7949bc0c46028904ff  split-1G_ai
cd573cfaace07e7949bc0c46028904ff  split-1G_aj
cd573cfaace07e7949bc0c46028904ff  split-1G_ak
cd573cfaace07e7949bc0c46028904ff  split-1G_al
cd573cfaace07e7949bc0c46028904ff  split-1G_am
cd573cfaace07e7949bc0c46028904ff  split-1G_an
cd573cfaace07e7949bc0c46028904ff  split-1G_ao
cd573cfaace07e7949bc0c46028904ff  split-1G_ap
cd573cfaace07e7949bc0c46028904ff  split-1G_aq
cd573cfaace07e7949bc0c46028904ff  split-1G_ar
cd573cfaace07e7949bc0c46028904ff  split-1G_as
cd573cfaace07e7949bc0c46028904ff  split-1G_at
cd573cfaace07e7949bc0c46028904ff  split-1G_au
cd573cfaace07e7949bc0c46028904ff  split-1G_av
cd573cfaace07e7949bc0c46028904ff  split-1G_aw
cd573cfaace07e7949bc0c46028904ff  split-1G_ax
cd573cfaace07e7949bc0c46028904ff  split-1G_ay
7036950003e53e471654b020330b386e  split-1G_az
0a82f6068a91bef3b46294e1e30687be  split-1G_ba
cd573cfaace07e7949bc0c46028904ff  split-1G_bb
cd573cfaace07e7949bc0c46028904ff  split-1G_bc
cd573cfaace07e7949bc0c46028904ff  split-1G_bd
cd573cfaace07e7949bc0c46028904ff  split-1G_be
cd573cfaace07e7949bc0c46028904ff  split-1G_bf

我想不断地分成更小的块来确定实际差异的大小，然后用十六进制编辑器对其进行分析，但我怀疑这会提供任何导致数据退化的原因的洞察力。我的 ISO 图像、视频文件和 EXT4 循环文件系统正在损坏。知道罪魁祸首是什么吗？

由于这仅在 32 GB 开始发生（恰好是我的 64 GB RAM 大小的一半。我没有使用交换。），我倾向于认为这是一个内存问题。你说什么？

更新#1：

不幸的是，内存测试并没有像预期的那么长。:-( 在此处输入图像描述

更新 #2（解决方案！）

我从计算机上卸下了所有 4 个 16 GB 的记忆棒。
然后我只将最低序列号的记忆棒插入第一个 DIMM 插槽，插槽 #1（我的插槽编号从 1 到 4）。我运行 MemTest86 3:44（三小时四十四分钟），它以零错误完成。
我用下一个按顺序编号的棒代替了那根棒（在明显的断电和静电预防措施之后）。我再次使用了 Slot #1（因为我希望在开始检查我的插槽之前先测试所有内存）。我再次运行 MemTest86。这一次，由于错误太多，测试几乎瞬间中止。
因此，我将第三个 DIMM 插入插槽 #1。MemTest86 运行了 3:43，没有错误。
Slot #1 测试中的第四个 DIMM 也运行了 3:43 并且没有错误。
然后我将三个已知良好的 DIMM 插入前三个插槽。MemTest86 运行了 8:54 并且没有任何错误。

我发现有趣的是，测试三个 DIMM (8:54) 所用的时间明显少于三个单模块测试的总和 (3:44 + 3:43 + 3:43 = 11:10)。我假设一些测试是同时进行的。

我sha256sum编辑了一个新的 32 GB zeros 文件。即使经过多次迭代，总和也保持不变。我的总和是97af759fc4597bc41706df77cbab318a57d935bacb262bd409e3ab767e07066f，与@bernard.wei 提供的数字相同。

我要感谢 @heynnema 对 MemTest86 的建议。这有助于解决这个问题。

我认为这件事已经解决了。谢谢大家！

18.04 LTS 上的文件损坏大文件 (32 GB) [已解决]

如何运行 .sh 脚本？

如何安装 .tar.gz（或 .tar.bz2）文件？

如何列出所有已安装的软件包

无法锁定管理目录 (/var/lib/dpkg/) 是另一个进程在使用它吗？

simmcrd's questions

18.04 LTS 上的文件损坏大文件 (32 GB) [已解决]

如何运行 .sh 脚本？

如何安装 .tar.gz（或 .tar.bz2）文件？

如何列出所有已安装的软件包

无法锁定管理目录 (/var/lib/dpkg/) 是另一个进程在使用它吗？