好的。 在例程擦洗后，我的MDADM RAID5报告mismatch_cnt = 16。据我所知，这意味着虽然没有设备报告读取错误，但有16个块的数据和奇偶校验不同意。
问题1：是否可以获得这些块的列表？
问题2：假设＃1是可能的，考虑到底层文件系统是EXT4，有没有一种方法来确定哪些文件与这些块相关联？
我有近线备份，在理想的情况下，我可以将实时arrays与备份数据区分开来，find任何已经被无声损坏的文件。 但事实是，回顾6TB的备份数据将会既昂贵又耗时。 知道去哪里看，什么恢复将大大简化事情。
（我应该注意到，我只用'check'选项来运行RAID擦洗，使用'repair'选项运行擦洗似乎非常危险，因为MDADM只知道数据或者奇偶校验是错误的，但是不知道哪一个是错误的。所以看起来MDADM有50％的机会猜测错误并重build不正确的数据，因此我希望知道哪些文件可能受到影响，以便我可以从备份中恢复它们（如有必要）
任何build议不胜感激！
对不起，“检查”确实会在遇到错误时回写数组 – 请参阅https://www.apt-browse.org/browse/ubuntu/trusty/main/amd64/mdadm/3.2.5-5ubuntu4/file /usr/share/doc/mdadm/README.checkarray
即使内核日志可能有其他build议（例如/ proc / mdstat和几个内核消息将提到“重新同步”），“检查”是一个只读操作。 也请参阅常见问题的第21个问题。
但是，如果在读取时发生读取错误，则检查将触发正常的读取错误，即生成“正确的”数据，并尝试写出错误 – 因此，“检查”可能会触发写。 但是在没有读取错误的情况下，它是只读的。
…因此，收集您要查找的数据可能已经太晚了，对不起。
从长远来看，值得注意的是RAID5（和6,1） 没有防止可能遇到的情况。 当一张光盘中的数据变坏时，他们无法确定哪一个数据好坏。 我build议计划迁移到每个磁盘（如btrfs或zfs）的校验和文件系统。
（RAID-5真的不应该用于新的部署 – 真的不应该在原始光盘的容量超过2TB的地方 – 见http://www.zdnet.com/article/why-raid-5-停止工作在2009年/ ）