Linux软件Raid在本月的第一个星期天运行checkarray？ 为什么？

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

1）RAID是正常运行/访问速度解决scheme，而不是备份解决scheme。 RAID的失败不应该意味着数据丢失，因为您不应该使用它。

2）我很好奇你为什么认为整个驱动器是“低效的”。 为什么增加复杂性，只能依靠计算机而不能错过什么东西？

3）“因为在磁盘发生故障的情况下，为大型和活动arrays重build镜像或奇偶校验磁盘可能需要几天时间 – 在此期间，如果另一个磁盘出现故障，则表示数据丢失。 而不是什么，把所有东西放在一个磁盘上？ RAID并不完美，但这意味着您可以在整个驱动器死亡的情况下继续存活而不会丢失对数据的访问权限，并且可以重新构build而不会丢失对数据的访问权限。 另外，除了RAID1之外，定期testing可以检测到一个变坏的驱动器（它跟踪特定驱动器的单个块故障，还使用SMART数据），并且可以将其标记为失败，然后再无法访问数据。 即刻，灾难性的驱动器故障并不是唯一的数据丢失情况。

检查RAID1仍然是有道理的，定期做这些事情应该让你的数据更安全。

这似乎是反直觉的，直到你深入研究驱动器如何失败。 我同意，如果两个磁盘不同步，检查将不会有任何好处。 但是如果其中一个磁盘有一个最近失败的扇区呢？ 那么，在检查期间从驱动器读取将产生该驱动器的读取错误，对吗？ 这对于RAID驱动程序来说是有价值的信息，因为它从镜像中知道存储在第二个驱动器上的信息应该存储在失败的扇区中。 因此，RAID驱动程序现在将尝试重写失败的扇区（即使在检查模式下，没有经验的用户所认为的只读）。 这种重写可能工作与否，但现代磁盘都有备用扇区，在写入时将会replace出现故障的扇区（而不是读取时，只会报告读取失败）。 因此，通过RAID驱动器重写扇区的组合，硬盘驱动器为故障磁盘重新分配备用扇区，RAIDarrays正在被固定。 RAID驱动程序实际上不知道（也不需要知道）发生了重新分配。 这是在驱动器本身内完成的，如果configuration正确（参见smartctl），操作系统可以发送一封电子邮件给pipe理员，告诉他一个扇区被重新分配，这意味着是时候更换缓慢出现故障的磁盘了。 现代大型磁盘倾向于产生这些“等待扇区”读取错误，例如由于温度波动。 在RAIDarrays中使用它们将显着提高可靠性，并且运行定期检查将确保有问题的扇区在读取问题时会自动刷新。 这些刷新写入实际上可能导致扇区上的成功写入操作，在这种情况下，“挂起的扇区”不会成为“重新分配的扇区”，换句话说，磁盘并不是真的不好，因为它能够现在写行业。

无论如何，通过使用smartctl并进行定期检查，您将使您的RAIDarrays更加可靠。 有关zfs的评论（例如zfs3或z3）也很重要。 随着硬盘规模的不断增长，随着信息编写密度越来越高，驱动器的devise更多地受到消费者市场而非服务器市场的驱动，每个存储单元数据丢失的总体风险急剧增加。 在数TB的驱动器上运行RAID5是有风险的，因为重build时间长，需要在重build过程中从其他所有驱动器进行广泛的读取。 如果您想要保护自己免受灾难性数据丢失故障（是的，这只是概率，而且还需要考虑其他因素，如控制器故障，断电等等），请考虑使用两个备用的RAID6。为了平衡许多不同部件的可靠性，你必须做很多事情）。 即使是RAID6，也可能比具有三个奇偶校验驱动器的可靠性低数百倍，如在RAIDZ和/或Z3中。

我同意zfs＆btrfs看起来像一个有趣的解决scheme比较正常mdadm RAID5（在某些情况下）。

但…

• btrfs没有稳定的版本。 你真的想冒这个险？
• zfs看起来很成熟 – 但是对于linux系统的解决scheme…有一点点缺陷。 保险丝？ 第三方本地内核模块？

我说坚持本地支持 – 关于mdadm RAID1 / 5/6上的LVM2 …

我的两分钱

Debian的mdadm软件包可以很容易地closures每月的checkarray，这一事实告诉我，这并不重要。 以下是您从dpkg-reconfigure mdadm获得的相关消息：

如果内核支持它（版本大于2.6.14），mdadm可以定期检查MDarrays（RAID）的冗余。 这可能是一个资源密集型的过程，具体取决于本地设置，但可以帮助防止罕见的数据丢失情况。 请注意，这是一个只读检查，除非发现错误; 如果发现错误，mdadm将尝试更正它们，这可能会导致对介质的写入访问权限。

就我个人而言，在我的1TB镜像（一个简单的文件服务器）上每月运行一次的checkarray脚本没有问题，因为在星期天的早上它只用了不到3.5个小时，反正没有其他事情发生。 在检查arrays引起明显的性能问题的情况下，我会毫不犹豫地将其closures，或者可能安排它不太频繁地运行（例如，每6个月，在某些假期等）。