自从我拥有个人电脑（30 年）以来，这是我第一次遇到未检测到、未纠正的单比特磁盘错误。在 RAID 阵列中。事件的顺序是
- 从 CF 卡上传一组数字图像（Camera Raw 文件）
- 在 Lightroom 中进行一些编辑（不会更新原始文件）
- 将所有内容备份到外部存档磁盘（使用 Retrospect）
...时间流逝（大约 1 周）... - 在 Lightroom 中再次打开该文件 - 它已损坏（一个大的方形洋红色斑点）
- 从存档磁盘恢复副本 - 恢复的副本未损坏
- 比较这两个文件。只有一个位不同……原本为 0x34 的字节现在为 0xB4
在线设备是一对 2TB 硬盘，采用 RAID-1 结构，位于硬件RAID 卡（3WARE 9560SE-4LPML）。
鉴于上述顺序，错误显然是在步骤 3 之后的某个时间引入的，因为存档副本没有损坏，所以它不可能在原始写入期间发生。该文件是佳能 CR2 原始文件，Lightroom 从不更新原始 RAW 文件，它们被视为“数字底片”并且从未更新。相反，它将所有编辑保存为包含应用的编辑序列的附属 XMP 文件。文件日期/时间与原始文件相比没有修改。
显然，位错误以某种方式发生了，并且由 RAID 硬件传播，而没有产生警告。我检查了 RAID 错误日志，过去 18 个月（自我上次升级软件和固件以来）没有什么值得注意的。
总结一下：
- 数据原本写入正确
- 当它被复制到备份时就可以被正确读取。
- 此后不久，情况发生了变化在磁盘上（因为没有任何东西重写该文件）。
- RAID 硬件设置为每周运行一次“验证”。它没有检测到错误。
这太奇怪了。我原本以为 RAID 硬件日志中会出现错误比较错误。
另外，我可以排除磁盘故障，因为两个驱动器上的 SMART 数据显示零对于所有适用的错误属性：
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0
其余一切也都只是名义上的。
有人知道在什么情况下会发生这种情况吗？未被发现？
答案1
一种可能性是在步骤 4 中读取时 RAM 或控制器中发生了随机位翻转。如果数据在读取时已损坏，那么您将在步骤 4 中看到它，然后如果它仍在缓存中，您还会在比较文件时在步骤 6 中看到它，因为损坏的缓存数据可能仍在使用。
要测试这种情况，请关闭所有硬件的电源以确保缓存已清除，然后尝试再次打开文件（并与备份进行比较）。如果一切正常，那么这就是问题所在（无法知道位翻转发生在读取的哪个阶段，因此您只能将其视为未解之谜）。†
除此之外，还有第二种更不幸的可能性，即在步骤 1 中写入时随机 RAM（或者更可能是 RAID 控制器，根据您的描述）位翻转；但尽管磁盘上存在损坏的副本，但您在步骤 2 和 3 中操作的是良好的缓存副本。一周后，当您再次访问数据时，您当然会从磁盘重新读取它，最终得到的是最初写入的损坏数据。这需要做出许多假设，并且需要一些运气。如果是这种情况，您只需恢复备份文件并继续。
我确实只能想到这两个问题。这听起来不像是驱动器本身的问题。无论如何，由于无法判断错误发生在硬件的哪个位置，我建议运行完整的内存诊断程序以防万一，尽管更可能是由于不幸的 EMI 或宇宙射线. 加拿大人 Luke 在他的回答，ECC RAM（如果您的主板支持）至少在 RAM 方面可以防止此类事件发生。实际上这并不罕见。
†这个案例最终是原贴作者的问题，而不是第二种可能性。
答案2
检查你的内存。zfs 等文件系统建议使用 ecc 内存（错误检查和纠正内存）来防止出现此类问题。
您的 RAID 控制器只是简单地写入了所给出的信息，并假定它获得了正确的信息。它不会检查所收到的信息是否正确，只是检查是否正确写入。
您的主板可能不支持 ecc 内存，但这应该可以解决这个问题。也可能是太阳耀斑改变了您的那个字节，因为您的内存越多，发生异常的可能性就越大。
我现在在外地，但我可以在周一引用消息来源