ZFS scrub卡顿重启后任务阻塞故障求助

故障现象 #

• 运行ZFS scrub任务时卡顿，重启服务器后ZFS完全停滞，zpool、zfs命令无限期无响应
• dmesg日志显示zpool、dp_sync_taskq、txg_sync、spa_async等任务阻塞超120秒，启动时触发内核恐慌：PANIC: zfs: attempting to increase fill beyond max; probable double add in segment [71ac2134000:71b02136000]
• 执行zdb -e -bc storage扫描至3.58TB时失败，报错zio_wait(zio_claim(NULL, zcb->zcb_spa, refcnt ? 0 : spa_min_claim_txg(zcb->zcb_spa), bp, NULL, NULL, ZIO_FLAG_CANFAIL)) == 0 (0x2 == 0x0)，重复测试结果一致
• 已完成内存测试及所有4块硬盘的SMART短测，均无异常

修复步骤 #

1. 只读模式导入池，优先备份数据

先尝试以只读模式导入池，避免写入操作进一步损坏元数据，同时备份关键数据：

zpool import -o readonly=on storage

若导入成功，立即将核心数据复制到外部存储介质。

2. 跳过故障段执行zdb深度扫描

修改zdb参数，从报错segment的结束地址开始扫描，定位具体损坏的元数据：

zdb -e -bc -s 71b02136000 storage

扫描完成后，重点关注报告中与double add相关的对象ID、块地址信息，这些是修复的核心目标。

3. 交互式修复元数据损坏

使用zdb的交互模式尝试修复损坏的元数据：

zdb -e -E storage

进入交互界面后，使用repair命令针对之前定位到的故障segment或对象进行修复。注意：此操作存在数据丢失风险，必须先完成数据备份。

4. 回滚事务组修复不一致

如果只读导入失败，尝试回滚到最近的可用事务组，修复scrub中断导致的元数据不一致：

zpool import -F storage

若-F参数无效，可尝试更激进的强制回滚（会丢失最近的写入数据，谨慎使用）：

zpool import -fF storage

5. 替换故障设备（镜像/RAID-Z池适用）

如果zdb检测到某块设备的元数据损坏，且池为镜像或RAID-Z配置，可尝试替换故障设备：

zpool replace storage /dev/故障设备路径 /dev/新设备路径

替换完成后运行scrub验证修复效果：

zpool scrub storage

6. 强制重建元数据索引

若以上方法均无效，尝试导出池后强制重建元数据索引：

zpool export storage
zpool import -o readonly=on -m storage

此操作耗时较长，需确保服务器有充足的CPU和内存资源支撑。

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