Linux 软件突袭在每月的第一个星期日运行 checkarray？为什么？

Question

看起来 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

感谢您的任何见解，

Answer 1

由于听起来您正在运行 RAID1，我同意您在您的情况下不需要检查，但我不同意第一个回答者给出的一些原因。

1) RAID 是 UPTIME/ACCESS SPEED 解决方案，而不是备份解决方案。RAID 失败并不意味着数据丢失，因为您不应该为此使用它。

2）我很好奇你为什么认为镜像整个驱动器是“低效的”。当您可以镜像所有内容时，为什么要增加复杂性并且必须依靠计算机不会丢失任何东西？

3) “有风险，因为在磁盘出现故障的情况下，为大型活动阵列重建镜像或奇偶校验磁盘可能需要几天时间 - 在此间隔内，如果降级阵列中的另一个磁盘出现故障，则意味着数据丢失。” 与什么相反，将所有内容保存在单个磁盘上？RAID 并不完美，但它确实意味着您可以在整个驱动器死亡的情况下幸存下来而不会失去对数据的访问权限，并且可以在不失去对数据的访问权限的情况下进行重建。此外，在 RAID1 以外的任何其他设备上，定期测试可以检测到变坏的驱动器（它跟踪特定驱动器的单个块故障，并且还使用 SMART 数据），并且可以在您无法访问之前将其标记为故障数据。立即发生的灾难性驱动器故障并不是唯一的数据丢失情况。

Answer 2

检查 RAID1 仍然有意义，定期检查应该可以使您的数据更加安全。

这似乎有悖常理，除非您深入了解驱动器是如何发生故障的。我同意如果两个磁盘不同步，则检查不会有任何好处。但是，如果其中一个磁盘的扇区最近发生故障怎么办？那么，在检查期间从该驱动器读取将产生该驱动器的读取错误，对吗？这对 RAID 驱动程序来说是有价值的信息，因为它从存储在第二个驱动器上的镜像信息中知道应该存储在故障扇区中的内容。因此，RAID 驱动程序现在将尝试重写失败的扇区（即使在检查模式下，没有经验的用户认为它是只读的）。这种重写可能有效，也可能无效，但现代磁盘都有备用扇区，这些扇区将在写入时替换故障扇区（而不是在读取时 - 读取时它只会报告读取失败）。因此，通过 RAID 驱动程序重写扇区和硬盘驱动器为故障扇区重新分配备用扇区的组合，RAID 阵列正在即时修复。RAID 驱动程序实际上不知道（也不需要知道）发生了重新分配。这是在驱动器本身内完成的，如果配置正确（请参阅 smartctl），操作系统可以向管理员发送一封电子邮件，告诉他一个扇区已重新分配，这意味着是时候更换缓慢发生故障的磁盘了。现代大型磁盘倾向于产生这些“未决扇区”读取错误，例如由于温度波动。在 RAID 阵列中使用它们将显着提高可靠性，运行定期检查将确保有问题的扇区在出现读取问题时自动刷新。

无论如何，通过使用 smartctl 并进行定期检查，您将使 RAID 阵列更加可靠。关于 zfs（例如 zfs3 或 z3）的注释也很重要。随着驱动器大小的增加，信息写入的密度越来越大，驱动器的设计更多地由消费市场而非服务器市场驱动，每个存储单元的数据丢失的总体风险急剧增加。在几 TB 大小的驱动器上运行 RAID5 是有风险的，因为重建时间很长，并且需要在重建过程中从所有其他驱动器中广泛读取。如果您想保护自己免受灾难性数据丢失故障的频率影响，请考虑使用带有两个备件的 RAID6（是的，这只是概率，您还需要考虑其他因素，例如控制器故障、断电...... 您需要做很多事情来平衡许多不同组件的可靠性）。甚至 RAID6 的可靠性也可能比 RAIDZ 和/或 Z3 中的三个奇偶校验驱动器低数百倍。