请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
因为个人有对归档文件全量 HASH 的习惯，近期迁移 NAS ，从 UNRAID 迁移部分影视文件到新建的 NAS ，校验某 1T 大小的影视文件夹时遇到单个文件 HASH 校验失败，还好可以通过互联网恢复，看到具体的损坏位置。
117603,117606c117591,117594 < "ed2k": "FDFF75DAFA7FD8F021F7A40C5A0207D7", < "md5": "23C34E593BBB73375D600A526C6A291E", < "sha1": "79AF053BF5BE32A7265382DB9041FE8D0F86F804", < "sha256": "36A6A32A5082D020DA35FD638E79A33294B264ECF07869C195856FD2D120132B" --- > "ed2k": "803F36E469191335169FC8EA7B95E504", > "md5": "518E50F7445DE606B2792CEE05157EE6", > "sha1": "717761CF027EB1F88D142E2C344080DEDE468246", > "sha256": "D44610A581BBFE241E9E97C6D362DA39DB3C14FF7BE03473CA53F483D6CD8A0E" licsber@10 Downloads % xxd ori.mkv > ori licsber@10 Downloads % xxd unraid.mkv > unraid licsber@10 Downloads % diff ori unraid 15246551c15246551 < 0e8a4d60: 882a a172 2e55 8626 ee7b 6be9 095d 7cb4 .*.r.U.&.{k..]|. --- > 0e8a4d60: 882a a072 2e55 8626 ee7b 6be9 095d 7cb4 .*.r.U.&.{k..]|. 可以看出来，一个 1 变成了 0 ，应该是奇怪的比特翻转。
暂时还想不起这个文件夹的由来，因为之前 PT 下载的机器和存储位置都变过很多次，自己挪文件大都通过 rsync ，并且每次删除源文件前，都会对目的位置做校验，所以应该不会是传输损坏，那静默损坏的可能性就很高。
搬迁前因为最近机器遇到过读写过程中突然断电，所以对单校验盘（ 8 盘 8T 留 1 盘做 SNAP RAID ）的 UNRAID 做了一次 check ，勾选了自动修正校验盘数据，但是之前修正计数都是 0 ，这次遇到一万多，所以开始排查问题。
原因分析
首先是不勾选自动修正校验盘，重新 CHECK 两遍，错误计数都是 0 ，可以基本排除软件逻辑本身问题。
不过排查日志发现了更严重的事情，这个机器是三年前在 B 站 优易电子 买的 万由 810A 套装，配了一块 微星 B460M PRO-VDH 主板，原装配了一条 4G 内存，自己又加了一条 16G 内存，买来之后才发现八盘位其中主板原生 SATA 只有 4 个，另外四个通过 M.2 转 SATA 实现，此为背景。
可能性 1:M.2 转 SATA 模块问题，但感觉底层不至于影响上层，而且这个也没缓存。
之前遇到过一次主板亮 DRAM 灯，无法启动，拔掉两根内存条，擦一擦，交换位置之后正常启动。
可能性 2:内存问题，兼容性（两条不一样大）或者内存损坏，但是试了试跑 memtest 可以 PASS 。
又排查启动日志和 dmesg ，发现一条 SATA 始终是 3Gb/s 速率，遇到了降速。
交换 M.2 转 SATA 的接口顺序，交换硬盘顺序后，发现是万由的机箱背板问题，但是查到 SATA 降速应该不影响数据本身内容的安全，只会增加硬盘 SMART 信息中 UDMA CRC error count 的计数，现在这个盘的数值是 556 。
可能性 3:硬盘背板问题，因 SATA 降速，可能引起损坏。
root@LicsberPro:~# for i in /dev/sd* ; do echo $i && smartctl -a $i | grep SATA ; done /dev/sda SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) /dev/sdb SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) /dev/sdc SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) /dev/sdd SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) /dev/sde SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) /dev/sdf SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) /dev/sdg SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) /dev/sdh SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) UDMA CRC Error 日志：
[ 35.757890] ata7.00: exception Emask 0x10 SAct 0x8000 SErr 0xba0100 action 0x6 [ 35.757898] ata7.00: irq_stat 0x08000000 [ 35.757899] ata7: SError: { UnrecovData PHYInt 10B8B Dispar BadCRC LinkSeq } [ 35.757904] ata7.00: failed command: READ FPDMA QUEUED [ 35.757906] ata7.00: cmd 60/e0:78:20:02:00/00:00:00:00:00/40 tag 15 ncq dma 114688 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) [ 35.757912] ata7.00: status: { DRDY } [ 35.757916] ata7: hard resetting link [ 35.761755] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms ovfl timer [ 35.761761] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules [ 35.761763] RAPL PMU: hw unit of domain package 2^-14 Joules [ 35.761765] RAPL PMU: hw unit of domain dram 2^-14 Joules [ 35.761766] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules [ 35.764759] cryptd: max_cpu_qlen set to 1000 [ 36.221271] intel_rapl_common: Found RAPL domain package [ 36.221277] intel_rapl_common: Found RAPL domain core [ 36.221280] intel_rapl_common: Found RAPL domain uncore [ 36.221282] intel_rapl_common: Found RAPL domain dram [ 36.226724] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 36.228189] ata7.00: configured for UDMA/133 [ 36.228201] sd 6:0:0:0: [sde] tag#15 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s [ 36.228206] sd 6:0:0:0: [sde] tag#15 Sense Key : 0xb [current] [ 36.228208] sd 6:0:0:0: [sde] tag#15 ASC=0x0 ASCQ=0x0 [ 36.228211] sd 6:0:0:0: [sde] tag#15 CDB: opcode=0x88 88 00 00 00 00 00 00 00 02 20 00 00 00 e0 00 00 [ 36.228214] I/O error, dev sde, sector 544 op 0x0:(READ) flags 0x80700 phys_seg 24 prio class 2 [ 36.228226] ata7: EH complete SATA 协商降速日志：
[ 19.636335] ata8: hard resetting link [ 20.108593] ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 20.110056] ata8.00: configured for UDMA/133 [ 20.110067] sd 7:0:0:0: [sde] tag#14 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s [ 20.110069] sd 7:0:0:0: [sde] tag#14 Sense Key : 0xb [current] [ 20.110071] sd 7:0:0:0: [sde] tag#14 ASC=0x0 ASCQ=0x0 [ 20.110073] sd 7:0:0:0: [sde] tag#14 CDB: opcode=0x88 88 00 00 00 00 00 00 00 01 08 00 00 00 f8 00 00 [ 20.110074] I/O error, dev sde, sector 264 op 0x0:(READ) flags 0x80700 phys_seg 31 prio class 2 [ 20.110083] ata8: EH complee [ 20.143988] ata8: limiting SATA link speed to 3.0 Gbps [ 20.143992] ata8.00: exception Emask 0x10 SAct 0x800000 SErr 0xb00100 action 0x6 [ 20.143994] ata8.00: irq_stat 0x08000000 [ 20.143995] ata8: SError: { UnrecovData Dispar BadCRC LinkSeq } [ 20.143998] ata8.00: failed command: READ FPDMA QUEUED [ 20.143999] ata8.00: cmd 60/08:b8:d8:01:00/00:00:00:00:00/40 tag 23 ncq dma 4096 in res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) [ 20.144004] ata8.00: status: { DRDY } [ 20.144006] ata8: hard resetting link [ 20.610811] ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 320) [ 20.612275] ata8.00: configured for UDMA/133 [ 20.612283] ata8: EH complete 等待后续继续排查。
 | 1 YsHaNg 18 小时 3 分钟前 via iPhone  1 有 fs 本身的校验位吗 btrfs 自带镜像校验信息 |
 | 2 billccn 17 小时 49 分钟前 1 最常见的就是内存随机翻转，没有 ECC 的话，研究表明 4GB 每 3 天就会有一位翻转： https://www.macobserver.com/columns-opinions/computer-makers-negligently-ignore-bit-flip-errors/ 不过你这个 SATA 链路上 CRC 错误是非常少见的故障，属于硬件信号完整性不佳。CRC 只能检测和修复特定数量的错误，超过的有可能检测不出来，这时候你上层（ RAID ，文件系统）也不做 checksum 的话，那数据就错了。 |
 | 3 Licsber OP |
 | 4 nuk 16 小时 41 分钟前 1 我有一条内存能过主板的 memtest ，但是 passmark 的 memtest 有一个算法过不去，开始运行都没问题，但是时间一长使用率上升后 zfs 就会报错，修复一下又没问题，查了蛮久才发现是内存问题 |
 | 5 WuSiYu 13 小时 47 分钟前 via iPhone 1 挺有意思的一次观察，能观察到数据静默错误还是挺少见的 首先定期校验的话个人认为不太可能是硬盘自身的位翻转，硬盘内部也有校验，每次读取时应该是会自动修复少量介质上随时间推移自然产生的位翻转 其次 op 机器的 sata 链路虽然看着确实不咋靠谱，几百的 udma crc error 在正常机器上是个很异常的数字，但考虑到 sata 链路是 32 位 crc ，只有几百次可检出错误的话不太可能会发生过未检错误，所以这个应该也能排除 那么最后最大的嫌疑就只能给到内存了 另外你用的应该不是 snap raid ，而是 unraid 默认的阵列功能（这俩不是一个东西）。snap raid 其实是能修正数据静默错误的，但它的冗余不是实时的 |
| 6 WuSiYu 13 小时 38 分钟前 via iPhone 1 另外你还说意外断电导致了 unraid 校验出现了一万多错误，这个也挺异常的，是意外断电时有在读写吗？这个倒也是可能的原因 另外建议也提供下硬盘型号 |
 | 7 Overfill3641 13 小时 9 分钟前 1 内存问题是挺常见的，之前下载文件偶尔会有哈希值对不上的情况，后面换了内存就没出现过了。 不过我做了冗余文件，倒是不怕这个，存档前校验通过就行。 |
| 8 Overfill3641 13 小时 4 分钟前 1 位衰减在便宜的 U 盘上倒是很常见，差不多一个月就有错误。 有些奇怪的 U 盘第一次验证失败，第二次验证又对了。 |
 | 9 kuanat 11 小时 59 分钟前 4 首先明确一个逻辑，就是判断一个写入行为是否正确，只能靠写入之后的再次读取来验证，但这个验证仅能代表这一次尝试读取时的结果，很可能下一次再读取就出错了。基于这个逻辑，所有的存储介质还有软件，都是不做这个检测的，而是在写入的时候，附带写入一个校验码，那么下次读取的时候，如果校验码和数据本身不一致，就认为之前写入的数据出错了。 如果这个静默错误发生在硬盘内部，比如因为宇宙射线或者某种原因造成的，那么硬盘固件会向操作系统汇报读取出错。根据你的描述来看，没有任何软件层面的提示，而是你人为校验的时候发现的，那就说明硬盘内部的校验信息和硬盘上实际的写入数据是一致的，由此可以判断，数据在进入硬盘之前就已经发生了变化。 再往上一层就是 xfs 文件系统了，由于 xfs 不像 zfs/btrfs 有数据块校验，同时会在读取的时候强制做验证，所以比较大的概率是，上一次写入时，xfs 获得的数据已经是错误的了，这个错误大概率是发生在内存中的静默错误。根据描述来看，硬件平台是没有 ecc 内存的，那么这种出错也就不可知了。 关于 bitrot 我在网上看到过很多次了，只是我个人从来没有遇到过，无论是很多年前组的 nas ，还是近几年接触维护过的带 ecc 内存的服务器，当然也有可能是遇到了但我不知道…… 我目前的应对方案是 cpu 开启内存加密，因为内存是 ddr5 本身有系统不可见的内部 ecc ，开内存加密可以让 1bit 的错误传播到最多 256bit ，提高发现的概率。文件系统方面都是 btrfs ，同时也采用 luks 加密，底层存储都是 btrfs raid1 ，都会大幅提高 bitrot 被发现的可能。迁移到这套配置很久了，我依旧没有遇到过静默出错的情况。 |
 | 10 msg7086 9 小时 52 分钟前 2 硬盘盘片出现 bitflip 只会触发硬盘本身的 ECC 校验修复（或者修复不成变成 pending reallocation ）。 出现直接数据错误的话，大概率是在电脑内部出了问题，也就是内存之类的地方出问题了。 |
 | 13 Huelse 7 小时 20 分钟前 理论上比特翻转每天都在发生，但因为 crc 和 ecc 等技术存在可以自动纠错一位。后续测试下翻转比特位所在扇区吧。 |
 | 14 tril 6 小时 11 分钟前 硬盘内的单位反转应该触发硬盘内部纠错，多位错误纠错失败会增加 BB/0E 计数（如果有的话），或者直接报坏扇区。如果硬盘本身没有检测到错误，而且多次读取又都是相同的错误数据，那我认为是一开始写进硬盘的数据错了。 现在是冬天，memtest86 压测 pass 并不一定真稳定。内存本身对温度很敏感，CPU 温度也会影响内存控制器的稳定性，所以压测内存需要提高机箱内温度。如果是南方，现在和夏天的温差能到 20 度甚至更高，差太大了。开暖气、堵风道、调低机箱风扇甚至裹保温等措施得用上。 SATA 降速是线路有问题，这应该会体现在链路 CRC 错误计数，计数不高说明降速之后链路还算稳定。 |
 | 15 zwzwzwzwzxt 4 小时 12 分钟前 我也遇到过类似的问题。同事的电脑下载大文件总是不对，发现每次下载都有随机几个字节的第 4 个 bit 位发生了翻转。最后换了网线就好了。 不过我不理解如果是传输的问题的话，网卡之类的硬件应该能校验出数据有误才对。可惜当时没有系统性的进行排查。 |
Select Language