ZFS Scrub 深度实践：校验和验证与静默损坏修复的工程化方案

为什么传统文件系统无法发现静默损坏

大多数文件系统默认存储设备返回的数据是正确的，除非硬件明确报错。这种信任模型在现代存储环境中存在致命缺陷 —— 位衰减、控制器故障、固件缺陷、内存错误甚至宇宙射线都可能在不被察觉的情况下破坏数据。当应用最终读取到损坏数据时，往往已经错过了最佳修复时机。

ZFS 采用 "不信任任何未经验证的数据" 的设计理念。每个数据块和元数据块都存储独立的校验和，这些校验和被保存在父级块的指针中，形成递归的 Merkle 树结构。当读取任意块时，ZFS 会重新计算校验和并与存储值比对，任何不匹配都会立即触发错误处理流程。

Merkle 树与校验链的验证机制

ZFS 的块指针设计是其数据完整性能力的核心。每个父块包含指向子块的指针，而每个指针中嵌入了对应子块的校验和。这种递归结构意味着：如果叶子数据块损坏，其父块的校验和验证会失败；如果父块本身损坏，祖父块的校验和同样无法通过。腐败无法向上传播隐藏，因为任何层级的损坏都会在读取时被检测。

现代硬盘的位错误率（BER）约为 1/10^15，意味着每读取约 100TiB 数据就可能遇到一次静默错误。对于当前动辄 16TB 以上的大容量硬盘，这仅相当于 6-7 次全盘读取。在缺乏校验机制的文件系统中，这种错误会悄然累积，直到冗余能力耗尽。

Scrub 的工作原理与自动修复

Scrub 是 ZFS 的主动完整性扫描机制。与按需读取时的被动校验不同，scrub 会遍历存储池中的所有已分配块，强制重新计算并比对校验和。这个过程不仅检查用户数据，还包括元数据块和 RAID-Z 的奇偶校验块 —— 许多描述错误地认为 scrub 只检查用户数据。

当 scrub 检测到校验和不匹配时，行为取决于池的冗余配置：

镜像配置：ZFS 从健康的镜像副本读取正确数据，覆盖损坏的副本。在三向镜像中，系统可以承受两个副本损坏仍能从第三个恢复。关键优势在于校验和使 ZFS 能够判断哪个副本是正确的，而传统 RAID 镜像只会简单同步两份数据，可能将损坏扩散到原本健康的副本。

RAID-Z 配置：ZFS 利用奇偶校验信息重建损坏的块，然后将修复后的数据写回磁盘。这个过程对用户透明，且修复后的块立即可用于后续读取。

这种 "自愈" 能力使 ZFS 能够在 corruption 尚处于可修复阶段时就将其消除，防止小错误累积到超出冗余容量的程度。

Scrub 与 Resilver 的本质区别

两者都是扫描操作，但目标和范围截然不同。Scrub 验证已存在数据的完整性，读取所有已分配块并检查校验和；resilver 则是在设备故障或更换后重建数据，只处理缺失设备上的块。

Resilver 可以跳过健康 vdev 上的数据以加速过程，而 scrub 必须读取所有数据（包括奇偶校验块）以确保完整性。因此 scrub 通常比 resilver 更耗时，但覆盖范围更全面。

调度策略与性能考量

推荐频率：大多数环境每月执行一次 scrub，关键系统建议每周。静态归档数据反而需要更频繁的 scrub，因为不常访问的数据最容易受到静默损坏影响。任何环境都不应超过 4 个月不执行 scrub。

性能影响：Scrub 是 I/O 密集型但 CPU 轻量的操作。它会读取池中的每个块，可能影响磁盘性能，但不会阻塞其他操作。建议在低峰期执行 scrub 以减少对延迟敏感应用的影响。

手动执行与监控：

# 启动 scrub
zpool scrub tank

# 查看进度
zpool status

# 停止 scrub
zpool scrub -s tank

关键监控指标解读

zpool status 输出中的 scrub 报告包含以下关键字段：

• scanned：已扫描的数据总量
• issued：实际读取的数据量
• repaired：修复的块数量（理想情况下应为 0）
• errors：检测到的错误数
• to go：预计剩余时间

CKSUM 列显示校验和不匹配次数，READ/WRITE 列显示设备级 I/O 错误。单个设备持续产生校验和错误通常预示硬件故障，即使 S.M.A.R.T. 未报警也应考虑更换。

修复块数量的小幅增加在大容量池中是正常的，但多次 scrub 间修复数量持续上升则表明硬件退化。应结合 zpool events 获取异步事件详情，并配置 ZED（ZFS Event Daemon）实现自动告警。

可落地的工程化检查清单

配置层面

• 确保池配置冗余（镜像或 RAID-Z），单盘池 scrub 只能检测无法修复
• 启用 ZED 自动事件处理，配置邮件 / Slack / 工单系统通知
• 建立 scrub 历史记录监控，追踪持续时间、修复数量、错误数量的趋势

运维层面

• 每月执行 scrub，关键系统每周执行
• scrub 期间监控 zpool status 的扫描速率和预计完成时间
• 对修复数量异常增加的设备立即进行硬件检查（线缆、控制器、固件）
• 保留独立于 ZFS 的备份，scrub 无法修复写入时已损坏的数据或人为误删

故障响应

• 单次 scrub 修复少量块：记录观察
• 多次 scrub 修复数量递增：计划更换可疑设备
• 单设备持续 CKSUM 错误：立即隔离并更换
• 无冗余池出现校验和错误：立即从备份恢复，该数据已不可访问

局限与补充策略

Scrub 是预防性维护工具，而非万能修复方案。它无法修复写入时就已经损坏的数据，也无法恢复被意外删除或覆盖的文件。对于写入损坏的情况，ZFS 会如实报告校验和错误，但如果没有冗余或备份，数据将永久丢失。

此外，scrub 的进度估计可能产生误导。早期阶段可能显示过短的完成时间，后期又可能显示过长的时间，这是因为 scrub 过程涉及不同 I/O 量的多个阶段。建议关注长期趋势而非瞬时数值。

资料来源

• Klara Systems - Understanding ZFS Scrubs and Data Integrity
• Saturn ME - ZFS Data Scrubbing: Deep Dive into Ensuring Data Integrity

systems