![“md value mismatch_count” 算什么?](https://linux22.com/image/1034963/%E2%80%9Cmd%20value%20mismatch_count%E2%80%9D%20%E7%AE%97%E4%BB%80%E4%B9%88%EF%BC%9F.png)
自从升级到 11.04 以来,我一直在尝试让我的 5 磁盘 RAID5 阵列重新上线。该阵列最初被分成两部分,我尝试使用带有假设清理选项的创建命令将其恢复为单个阵列。我认为这弊大于利,因为 mdadm 默认现在使用 1.2 而不是 0.90 元数据格式,我相信这导致元数据覆盖了我的部分数据。这让我对我认为阵列应该具有的磁盘顺序产生了怀疑,因为这种顺序不会导致可安装的驱动器,因此我使用脚本测试了五个磁盘的所有可能顺序,但没有一个安装成功,然后我尝试了相同的过程,只是我没有安装,而是运行了 xfs_check,然后是目标 xfs_repair(使用 -n 选项以防止任何实际编辑)。
所有这些使我得到了一个相当小的磁盘布局集合,但是我显然只有一次更改来尝试 xfs_repair,而且数据太大而无法尝试备份,所以我认为让阵列运行奇偶校验是个好主意,我从两个我认为最有可能正确的阵列磁盘顺序开始运行检查,结果发现它们都有 8 个 mismatch_count,而且这 8 个几乎是立即发现的。这怎么可能?这两个磁盘顺序非常不同(acbde 与 adcbe)......磁盘顺序可能对奇偶校验没有影响吗?只对实际底层数据有影响?如果是这样,尝试从其中一种布局对阵列运行修复,然后重新检查文件系统以查看它现在是否可以挂载可能是合理的......但我犹豫不决,因为这是我采取的第一步,故意将超过元数据写入磁盘。
答案1
好奇的任何人,事实证明我的问题是阵列创建和我运行新创建的 mdadm 版本之间的第二次默认更改,条带大小默认值为 64k,现在为 512k。切换到 64k 解决了我的问题。
答案2
这听起来确实是一个最适合 md 列表的主题。Neil Brown 最了解您的元数据更新以及它可能如何影响磁盘清理器。如果事实证明这不是问题,那么您只需执行“修复 > sync_action”即可修复阵列。