Linux Software Raid在本月的第一个星期日运行checkarray?为什么?

前端之家收集整理的这篇文章主要介绍了Linux Software Raid在本月的第一个星期日运行checkarray?为什么?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
看起来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

感谢您的任何见解,

解决方法

由于听起来你正在运行RAID1,我同意你不需要检查你的情况,但我不同意第一个回答者给出的一些理由.

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

2)我很好奇为什么你认为镜像整个驱动器是“效率低下”.为什么要增加复杂性并且必须依赖计算机而不是丢失某些东西,而只能反映一切?

3)“风险,因为在磁盘发生故障的情况下,为大型和活动阵列重建镜像或奇偶校验磁盘可能需要数天 – 在这个时间间隔内,如果来自降级阵列的另一个磁盘发生故障,则意味着数据丢失.”与什么相反,将所有内容保存在一个磁盘上? RAID并不完美,但它确实意味着您可以在整个驱动器死亡的情况下幸存而不会丢失对数据的访问权限,并且可以在不丢失对数据的访问权限的情况下重新使用REBUILD.此外,除了RAID1之外的任何其他内容,定期测试可以检测到正在变坏的驱动器(它跟踪特定驱动器的各个块故障,并且还使用SMART数据)并且可以在失去访问权限之前将其标记为失败.数据.即时,灾难性的驱动器故障并不是唯一的数据丢失情况.

猜你在找的Linux相关文章