我有一个 24 驱动器 zpool，由 3 个 RAIDZ1 vdev 组成，每个 vdev 运行 8 个 Seagate Exos X18 16TB 驱动器。它位于 Supermicro MB 上，配备 64 核（128 线程）AMD Threadripper Pro 和 256GB ECC RAM。
清理期间的系统利用率显示每次最多使用 2 个 CPU，并且总清理时间看起来可能需要五到七天。
有没有办法让所有 CPU 核心并行执行清理工作以加快速度？
答案1
CPU 很可能不是性能的限制因素。7200 RPM 主轴大约有 60 到 70 个随机 IOPS。即使是 24 个磁盘，也不会为优先级较低的完整性检查留下太多的备用性能。
计划每周进行一次清理。如果您的恢复点目标是来自夜间备份，则恢复源将不会被完全清理。也许是一些快照。这对您来说可能是可以接受的。
考虑使备份与清理保持一致。如果您每周进行一次完整备份，并在那时开始清理，则它可能会在下周完整备份之前完成。为阵列的完整性提供额外的保证，并通过代理确保备份的完整性。但是，没有太多时间来进行备份并进行良好的文件系统完整性检查。考虑保留多个完整备份以方便使用。多少天前的存档对您的恢复目标有多大用处取决于您，但至少应该完成相关的清理。
答案2
看来 ZFS 磁盘读/写操作的并行化工作正在进行中，但是尚未准备好进行测试。
用于指导响应的参数和一些数学知识：
每个驱动器的容量：16,000,000,000,000 字节（不是 16TB）。
持续读/写速度：270MB/s（258 MiB/s）。
平均故障间隔时间：285年。
每位读取的不可恢复扇区读取错误：每读取 116,415 TB 数据出现 1 位错误。
随机读取 4K QD16 QCD：170 IOPS。
随机写入 4K QD16 QCD：550 IOPS。
每个 8 驱动器 RAIDZ1 vdev 连接到一个 8 通道 PCIe 3.0x HBA，支持每个连接驱动器 512MB/秒的持续吞吐量。
HBA 连接到 128 通道主板上的 PCI4.0 x16 插槽。
该系统并行运行，支持在 22 小时内完成对所有 24 个 16TB 驱动器的读取。
我的预期是清理工作应在 24 小时内完成；因此，瓶颈在于校验和验证的 CPU 利用率。考虑到每个驱动器有 5 个计算线程（这是一个 128 线程/24 驱动器系统），校验和的并行化应该可以解决瓶颈问题。
根据可靠性：
随机理论预测，鉴于制造商的 MTBF 为 285 年，并假设置信区间为六个标准差，驱动器发生故障的可能性不大。尽管如此，我还是将 4 个驱动器用于纠错和灾难恢复。
位腐烂（每次读取位时不可恢复的扇区读取错误）是另一个问题，这就是我担心清理操作的原因。预期错误率为每读取 116,415 TB 数据出现 1 位错误。这意味着每 14 年会出现 1 位读取错误，如果 270MB/s 的全吞吐量连续读取可以维持 14 年，则为 24x7。
该机器是热故障转移 1024 节点、1 PB 集群的一部分。