ZFS Scrub 变慢，说明设计有缺陷
If Scrubs Hurt, Your ZFS Design Is Broken
当每月的 ZFS scrub 导致应用延迟飙升，运维人员往往选择推迟或取消检查，但这其实是系统在发出警报。如果最低优先级的只读扫描都能拖垮生产环境，说明存储池根本没有性能余量。问题通常源于容量规划失误：池子填得太满导致碎片化，以及 RAIDZ 架构在随机 IOPS 上的先天不足。真正的解决方案不是调整参数，而是重新设计架构。通过引入 Special VDEV 将元数据卸载到 NVMe 设备上，可以彻底解决随机读取瓶颈，让 scrub 回归其作为后台静默守护者的本质，确保在磁盘故障时能安全完成 resilver。
scrub 并没有制造这种状况，它只是测量并揭示了问题所在。
- zenoprax
我参加过一些网络研讨会，也经常在播客里听 Allan 的节目，这篇由 LLM 撰写的帖子读起来让人很痛苦。如果我不早就熟悉他及其工作，根本不会把这篇东西当回事。他是 ZFS 调优的坚定拥护者，而调优的前提是了解你的工作负载，他也为此写过其他指南。
1. 就我个人的经验而言，大多数使用 ZIL 来加速同步写入的人其实是在浪费空间。你只需要 5 秒的峰值吞吐量（对于 10Gb 连接来说大约是 5 GB）。与其占用整个设备，不如创建一对 25 GB 的分区作为 ZIL。
2. 用剩余的空间配置一个镜像 Special VDEV，并大量使用小数据块。32k 的块大小仍能留出一些压缩空间，除了节省空间外，这还能提高吞吐量并降低 IO/ps。
3. 当工作负载预计会很重，或者根据移动平均数显示实际负载很重时，暂停 scrub（`zpool scrub -p`），待安全时再恢复。哪怕是我的 24 TB NAS，在没有其他活动的情况下，scrub 也要运行 24 小时以上。
- toast0
> 容量大小是可以测量的，而不是靠猜。`zdb -bb tank` 可以按块类型分解已分配的空间；将非数据类别的数值相加，你就得到了当前的元数据占用量。
当然，在慢速阵列上，这也不是个快命令；我那个半满的 2x 24TB 镜像阵列，估计运行这个命令需要约 12 小时；而上一次 scrub 运行了刚过 24 小时。（发帖后，剩余时间降到了 10 分钟……看起来没之前那么慢，但还是很慢，而且占用了大量 I/O）
- secabeen
我拥有的每个 100+ TB 的 ZFS 存储池都是针对流式读写进行优化的。在这些规模下，IOPS 很少成为瓶颈。