看起来 Debian 默认在每月第一个星期日运行 checkarray。
这会导致我的 2TB 镜像出现严重的性能问题，并且磁盘使用率会持续 12 小时。“以防万一”这样做对我来说很奇怪。无论如何，在没有仲裁的情况下发现两个磁盘之间的数据不同步都会失败。
这项大规模检查只能告诉我，我的驱动器出现不可恢复的故障，数据损坏。好的，但并不是那么有用。必要的？
假设我没有磁盘错误，也没有理由相信我的磁盘出现故障，为什么需要进行此项检查？我应该将其从我的 cron 中移除吗？
/etc/cron.d# tail -1 /etc/cron.d/mdadm
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet
感谢您的见解，
答案1
因为听起来您正在运行 RAID1，所以我同意在您的情况下不需要检查，但我不同意第一个回答者给出的一些理由。
1) RAID 是一种正常运行时间/访问速度解决方案，而不是备份解决方案。RAID 发生故障并不意味着数据丢失，因为您不应该将其用于此目的。
2) 我很好奇您为什么认为镜像整个驱动器是“低效的”。既然您可以镜像所有内容，为什么还要增加复杂性并必须依赖计算机不遗漏任何内容呢？
3) “风险很大，因为一旦发生磁盘故障，为大型活动阵列重建镜像或奇偶校验磁盘可能需要数天时间 - 在此期间，如果降级阵列中的另一个磁盘发生故障，则意味着数据丢失。”与将所有内容保存在单个磁盘上相反？RAID 并不完美，但它确实意味着您可以在整个驱动器损坏的情况下幸存下来而不会失去对数据的访问权限，并且可以重建而不会失去对数据的访问权限。此外，在 RAID1 以外的任何驱动器上，定期测试都可以检测到正在变坏的驱动器（它会跟踪特定驱动器的单个块故障，并使用 SMART 数据）并在您失去对数据的访问权限之前将其标记为故障。立即发生灾难性的驱动器故障并不是唯一的数据丢失情况。
答案2
检查 RAID1 仍然有意义，定期检查可以使您的数据更加安全。
这似乎违反直觉，除非你深入了解驱动器故障的原因。我同意，如果两个磁盘不同步，检查将没有任何用处。但是，如果其中一个磁盘的某个扇区最近发生故障怎么办？那么，在检查期间从该驱动器读取将产生该驱动器的读取错误，对吗？这对 RAID 驱动程序来说是很有价值的信息，因为它从存储在第二个驱动器上的镜像信息中知道应该在故障扇区中存储什么。因此，RAID 驱动程序现在将尝试重写故障扇区（即使在检查模式下，缺乏经验的用户会认为这是只读的）。这种重写可能有效，也可能无效，但现代磁盘都有备用扇区，这些备用扇区将在写入时替换故障扇区（而不是在读取时 - 在读取时它只会报告读取失败）。因此，通过 RAID 驱动程序重写扇区，以及硬盘驱动器为故障扇区重新分配备用扇区，RAID 阵列正在动态修复。 RAID 驱动程序实际上并不知道（也不需要知道）发生了重新分配。这是在驱动器本身内完成的，如果配置正确（请参阅 smartctl），操作系统可以向管理员发送电子邮件，告诉他某个扇区已重新分配，这意味着是时候更换这个慢慢出现故障的磁盘了。现代大型磁盘往往会产生这些“待处理扇区”读取错误，例如由于温度波动。在 RAID 阵列中使用它们将显著提高可靠性，并且定期检查将确保有问题的扇区在出现读取问题时会自动刷新。这些刷新写入实际上可能会导致对该扇区的写入操作成功，在这种情况下，“待处理扇区”不会变成“重新分配扇区”，换句话说，磁盘实际上并没有那么糟糕，因为它现在能够写入该扇区。
无论如何，通过使用 smartctl 并定期检查，您将使 RAID 阵列更加可靠。关于 zfs（例如 zfs3 或 z3）的评论也很重要。随着驱动器大小的增加，信息写入更加密集，驱动器的工程更多地由消费者市场而不是服务器市场驱动，每个存储单元数据丢失的总体风险急剧增加。在几 TB 大小的驱动器上运行 RAID5 是有风险的，因为重建时间很长，并且需要在重建期间从所有其他驱动器大量读取。如果您想保护自己免受灾难性数据丢失故障频率的影响，请考虑使用具有两个备用驱动器的 RAID6（是的，这只是概率，您还需要考虑其他因素，例如控制器故障、断电……您必须做很多事情来平衡许多不同组件的可靠性）。甚至 RAID6 的可靠性也可能比拥有三个奇偶校验驱动器（如 RAIDZ 和/或 Z3）低数百倍。
答案3
我同意，与普通的 mdadm RAID5 相比，zfs 和 btrfs 看起来是一个有趣的解决方案（在某些情况下）。
但...
- btrfs 没有稳定版本。你真的想冒这个险吗？
- zfs 似乎已经成熟 - 但 Linux 系统的解决方案... 有点不完整。FUSE？第三方原生内核模块？
我说坚持使用本机支持 - 在 mdadm RAID1/5/6 上的 LVM2 上...
我的看法。
答案4
Debian 的 mdadm 软件包可以轻松关闭每月的 checkarray，这一事实让我意识到这并不是很关键。以下是您从 获得的相关信息dpkg-reconfigure mdadm：
如果内核支持（版本高于 2.6.14），mdadm 可以定期检查 MD 阵列（RAID）的冗余度。这可能是一个资源密集型过程，具体取决于本地设置，但它可以帮助防止极少数情况下的数据丢失。请注意，除非发现错误，否则这是一个只读检查；如果发现错误，mdadm 将尝试纠正它们，这可能导致对媒体的写访问。
就我个人而言，我并不介意每月在我的 1TB 镜像（一个简单的文件服务器）上运行一次 checkarray 脚本，因为它在周日早上运行不到 3.5 小时，而且没有其他事情发生。如果 checkarray 导致明显的性能问题，我会毫不犹豫地将其关闭，或者将其安排为运行频率较低（例如每 6 个月、在某些节假日等）。