FreeNAS 9.1 RAIDZ配置中健康硬盘Scrub时被离线的问题求助

老兄，我之前维护RAIDZ池时也碰到过scrub中途卡壳的情况，结合你描述的场景——4盘RAIDZ配置、曾有硬盘自动离线、意外断电后手动上线硬盘，咱们一步步来排查解决：

• 先查scrub状态与系统日志
  先运行zpool status -v，重点看scrub进度、硬盘的错误计数（read/write/checksum错误）以及池的健康状态。同时开个终端实时监控系统日志：tail -f /var/log/messages，留意有没有IO错误、zpool相关的报错——很多时候scrub卡壳是因为某块硬盘处理特定数据块时出现隐性IO问题。

• 重新验证曾离线的硬盘
  虽然之前SMART测试通过，但意外断电可能留下隐性坏扇区。针对那块重新上线的硬盘，运行smartctl -t long /dev/adaX（把X换成对应硬盘编号，比如ada2）做一次完整长时SMART测试，完成后用smartctl -a /dev/adaX查看结果，重点关注Reallocated_Sector_Ct、Current_Pending_Sector这类指标，确认有没有潜在故障。

• 重置zpool状态后重启scrub
  如果日志没明显报错，先暂停当前卡住的scrub：zpool scrub -s 你的池名称，然后导出再导入zpool（操作前确保没有客户端挂载使用这个池）：

  zpool export your_pool_name
  zpool import your_pool_name
  

  完成后重新启动scrub：zpool scrub your_pool_name，断电导致的元数据临时异常，往往能通过导出导入修复。

• 检查系统资源瓶颈
  FreeNAS 9.1的RAIDZ scrub对CPU、内存和磁盘IO占用不低，用top看CPU和内存使用率，用iostat -x 1监控磁盘IO利用率、响应时间。如果某块硬盘%util一直100%，或者内存被占满，可能是资源不足拖慢了scrub，这时可以暂时关闭其他高占用服务，给scrub让路。

• 极端情况：排查硬盘隐性故障
  如果上面的步骤都没用，大概率是那块曾离线的硬盘有隐性故障（比如磁头不稳定）。有备份的话可以考虑替换这块盘；没备份的话，先把重要数据拷贝出来，再尝试用zpool replace替换硬盘后重新做scrub。

内容的提问来源于stack exchange，提问作者James