好的。例行清理后，我的 MDADM RAID5 报告 mismatch_cnt = 16。据我所知，这意味着虽然没有设备报告读取错误，但有 16 个块的数据和奇偶校验不一致。
问题 1：可以获得这些块的列表吗？
问题 #2：假设 #1 是可能的，鉴于底层文件系统是 EXT4，有没有办法识别哪些文件与这些块相关联？
我确实有近线备份，在理想情况下，我可以将实时阵列与备份数据进行比较，以找到任何已被悄悄损坏的文件。但现实情况是，召回 6TB 的备份数据既昂贵又耗时。知道在哪里查看和恢复什么将大大简化事情。
（我应该注意，我只使用“检查”选项运行 RAID 清理。使用“修复”选项运行清理似乎非常危险，因为 MDADM 只知道数据或奇偶校验错误，但不知道哪个是错误的。因此，MDADM 猜测错误并重建错误数据的可能性似乎为 50%。因此，我希望知道哪些文件可能受到影响，以便我可以在必要时从备份中恢复它们）
任何建议非常感谢！
小智 1
抱歉，“检查”在遇到错误时确实会写回数组 - 请参阅https://www.apt-browse.org/browse/ubuntu/trusty/main/amd64/mdadm/3.2.5-5ubuntu4/file /usr/share/doc/mdadm/README.checkarray
“check”是一个只读操作，即使内核日志可能另有建议（例如/proc/mdstat 和一些内核消息将提到“resync”）。另请参阅常见问题解答的问题 21。
然而，如果在读取时发生读取错误，则检查将触发对读取错误的正常响应，即生成“正确”数据并尝试将其写出 - 因此“检查”可能会触发写。然而，在没有读取错误的情况下，它是只读的。
...所以现在收集您正在寻找的数据可能已经太晚了，抱歉。
从长远来看，值得注意的是 RAID5（以及 6 和 1）没有针对位腐烂的保护，这很可能是您遇到的情况。当一张光盘中的数据变坏时，他们无法确定哪些数据是好是坏。我建议计划迁移到对每个磁盘进行校验和的文件系统，例如 btrfs 或 zfs。
（RAID-5 确实不应该在新部署中使用 - 并且在每个原始磁盘容量超过 2TB 的情况下确实不应该使用 - 请参阅http://www.zdnet.com/article/why-raid-5- 2009 年停止工作/）