这是后续我疯狂的mdadm问题。我试图sda首先找出可能导致不同步的原因。我唯一能想到的是我刚刚运行了一堆更新并重新启动以重新加载内核升级。两个驱动器是否有可能未同步？如果正在进行 mdadm 同步，系统会阻止重新启动吗？可以做到吗？关于可能发生的情况还有其他建议吗？以及如何进一步预防这种情况。驱动器似乎没有任何问题。
答案1
它肯定会在干净关闭时起作用：
这Debian mdadm 常见问题解答意味着内核做了正确的事情：
8.我的（其中一个）RAID 阵列正忙且无法停止。是什么赋予了？
mdadm 在关闭时报告根文件系统的阵列正忙，这是完全正常的。原因是必须挂载根文件系统才能停止阵列（否则 /sbin/mdadm 不存在），但要停止阵列，则无法挂载根文件系统。 Catch 22. 内核实际上在停止之前停止了数组，所以一切都很好。这md 驱动程序在关机时将所有设备设置为只读（甚至给物理设备大约一秒钟的时间来解决）。
即使您的系统在写入过程中崩溃，驱动程序也会在写入时小心地将块标记为脏块，并在从不干净的数组开始时重新同步脏块。请参阅关于数组状态的评论。这内核文档警告脏（未完全关闭）和降级（丢失部分）的阵列不会自动组装，因为这不安全。当您组装脏数组时，您将（可能非常简短）resync在/sys/block/md99/md/rd0/state.总而言之，md 驱动程序负责保护您的数据免受硬件组件（CPU 或磁盘）完全故障的影响，这正是人们对它的期望。
md 无法保护您免受由于 RAM、CPU、主板或磁盘中的拜占庭故障（即一位或多位的静默翻转）导致的数据损坏。磁盘硬件有校验和，但它们并不完美（参见例如ZFS 宣传资料）。 兹夫斯和Btrfs可以防止存储设备损坏。Btrfs 的校验和树确保您的硬盘发生一点变化时会收到通知。 Zfs 提供校验和选择（根据杰夫·邦威克的博客），最高可达 SHA-256，不仅可以防止随机损坏，甚至可以防止蓄意攻击，但会消耗 CPU 周期。
答案2
您是否在将文件系统放入 raid1 之前创建了它？如果没有 - 您在将文件系统设为 raid 设备之前是否缩小了文件系统？
如果你不这样做，结果可能是你的 raid 设备上有一个坏的超级块。