关于ZFS scrub并行化支持及多核心CPU下加速24盘RAIDZ1存储池scrub的咨询

首先得明确一点：ZFS scrub的并行能力其实和vdev结构、ZFS版本以及你配置的参数密切相关，你的硬件确实拉满了，但默认设置下scrub的并行度没跟上你的CPU规格。

先说说ZFS scrub的默认并行逻辑 #

• 默认情况下，ZFS scrub是按vdev维度并行处理的，而不是直接把任务拆分给所有CPU核心。你有3个RAIDZ1 vdev，理论上最多能跑3个并行的scrub线程（每个vdev对应一个），这就是你看到最多2个CPU被利用的原因——可能某个vdev的线程暂时处于空闲状态，或者默认的线程数限制比vdev数量还低。
• 重点：单个RAIDZ vdev的scrub操作本身是单线程的，这是RAIDZ的架构决定的——校验块的计算依赖同条带内所有数据块的顺序处理，没法拆分成多个核心并行执行。

可以调整的参数和优化方向 #

• 调整scrub线程数上限：
  你可以通过zfs set scrub_limit=<number> <你的存储池名称>来提升允许的scrub线程数。比如你的3个vdev，把这个值设为3（或者保守点设为4留冗余），这样每个vdev都能分配到一个scrub线程，至少能把CPU利用率拉到3个核心左右。注意这个参数的最大值不能超过你存储池的vdev总数，多了也没用。
• 检查并升级ZFS版本：
  如果你用的是比较老的ZFS版本，建议升级到OpenZFS 2.0+的稳定版。新的版本对scrub的并行化有不少优化，比如新增了后台线程处理元数据校验、优化了IO调度逻辑，能间接提升整体效率。可以用zfs version查看当前版本。
• 优化ARC缓存与IO调度：
  你的256GB ECC RAM完全够用，确保ARC的大小设置合理（默认是系统内存的一半左右），可以用arcstat命令查看当前ARC的使用情况。足够的ARC能减少磁盘IO等待，让scrub线程更高效运行，间接提升CPU利用率。
  另外，对于机械硬盘为主的存储池，把IO调度器改成mq-deadline或者noop会比默认的cfq更合适，减少IO队列的延迟。临时调整可以用echo mq-deadline > /sys/block/<磁盘设备名>/queue/scheduler，要永久生效的话可以配置udev规则。

关于“用满64核心”的可能性 #

很遗憾，目前ZFS还做不到让单个RAIDZ vdev的scrub任务拆分到多个核心并行——这是RAIDZ的架构限制，没法绕过。所以你没法让所有64个核心都投入到scrub工作，但通过上面的优化，至少能把并行度拉到和vdev数量匹配的水平，把5-7天的scrub时间压缩到更合理的范围（比如2-3天，具体取决于你的磁盘实际性能）。

最后提个注意事项 #

调整scrub线程数的时候，别贪多——过多的并行scrub线程会大幅增加磁盘IO负载，可能影响存储池的正常业务。建议在业务低峰期调整并测试效果。

备注：内容来源于stack exchange，提问作者docBrian