好的。在例行清理后，我的 MDADM RAID5 报告 mismatch_cnt = 16。据我了解，这意味着虽然没有设备报告读取错误，但有 16 个块的数据和奇偶校验不一致。
问题 1：可以获得这些区块的列表吗？
问题 #2：假设 #1 是可能的，假设底层文件系统是 EXT4，有没有办法识别哪些文件与这些块相关联？
我确实有近线备份，在理想情况下，我只需将实时阵列与备份数据进行比较，即可找到任何已悄然损坏的文件。但现实情况是，恢复 6TB 的备份数据既昂贵又耗时。知道在哪里查找以及恢复什么将大大简化事情。
（我应该注意，我只使用“检查”选项运行 RAID 清理。使用“修复”选项运行清理似乎非常危险，因为 MDADM 只知道数据或奇偶校验有误，但不知道哪个是错误的。因此，MDADM 猜错并重建错误数据的可能性似乎有 50%。因此，我希望知道哪些文件可能受到影响，以便在必要时从备份中恢复它们）
非常感谢您的任何建议！
答案1
抱歉，当遇到错误时，“check”确实会写回数组 - 请参阅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-stops-working-in-2009/）