故障磁盘上的 ext4。如何避免以只读方式重新挂载?

故障磁盘上的 ext4。如何避免以只读方式重新挂载?

问题:

我负责一个由 44 个节点组成的 Hadoop 集群。我们有 1.5TB 的 WD Green Drives,存在(完全未知的)加载周期计数问题。

这些磁盘工作正常,但随着使用时间的增加,坏块数量不断增加。重写这些坏块一段时间后就会恢复正常,但它们又会重新出现在不同的地方。

由于这些磁盘大部分仅用于 Hadoop 数据节点,而我们没有足够的预算来替换它们,因此我正在寻找一种策略来

  1. 不要疯狂维护集群,磁盘错误和相关的文件系统问题几乎每天都会出现。我当前的程序是:

    • 停止 Hadoop 服务,卸载磁盘,使用dmesg输出和定位坏块,smartctl并使用重写这些坏块hdparm --write-sector
    • fsck -f -y在磁盘上运行并重新挂载它。
  2. 保持系统稳定。

    • Hadoop 负责处理磁盘错误(3 倍冗余),但我不想冒文件系统损坏的风险。

我做了什么?

目前我已将mount选项更改为:

  • erros=continue,noatime 但由于日志错误,我偶尔会以只读方式重新挂载。

然后我尝试禁用日志:

  • tune2fs -O ^has_journal 这可以避免只读重新挂载,但似乎会损坏文件系统(这是有道理的,没有日志)

现在我正在考虑换成

  • tune2fs -o journal_data_writebackmountdata=writeback,nobh,barrier=0

但我不确定这是否会重新引入只读重新挂载。

因此,我想避免只读重新挂载,希望维护稳定的文件系统元数据,但不关心数据中的错误(Hadoop 会处理这个问题)。速度也不会受到影响。

我有什么选择?我知道这对任何系统管理员来说可能都是一场噩梦。操作系统分区已安装完整日志记录,我不会在生产数据上进行测试。这仅适用于 Hadoop 数据节点/任务跟踪器硬盘。

答案1

您能做的最好的事情就是更换磁盘。磁盘的成本与集群停机的成本以及您修复坏块所花费的工作时间相比根本不值一提。因此,即使没有预算,我也会认真尝试说服您的管理层。

答案2

如果您确实需要使用这些驱动器,我建议使用mkfs -c -c…mkfs 检查文件系统是否有坏块。

您可以尝试其他文件系统(例如 btrfs),看看是否效果更好,但最终正确的答案是“更换磁盘”。

相关内容