故意破坏 ZFS 文件：从原理到实践的深度解读

背景

ZFS 的核心设计哲学之一是数据的完整性与自愈合能力（Self-healing）。在绝大多数生产场景中，ZFS 通过校验和（Checksums）和冗余机制确保数据不会发生静默损坏。然而，在开发、测试或深入理解文件系统底层机制时，有时我们需要反其道而行之：制造可控的、可复现的数据损坏，以观察 ZFS 的自愈过程、查看 scrub（磁盘扫描）报告，或者仅仅为了理解文件是如何映射到物理磁盘上的。

本文源自 Hacker News 上的一篇技术分享，作者通过在 Linux 环境下使用文件模拟磁盘，演示了两种“故意破坏” ZFS 文件的方法：一种是利用 zinject 工具的“懒惰”方式，另一种是通过手动计算 DVA（Data Virtual Address）并直接修改底层镜像文件的“教育”方式。后者旨在揭示 ZFS 内部的数据布局逻辑，特别是关于压缩、块指针以及文件偏移量的计算陷阱。

核心内容

1. 准备工作：构建基于文件的 ZFS 池

为了避免在真实物理磁盘上操作带来的风险，作者选择使用普通文件来模拟 ZFS 的 vdev（虚拟设备）。这种方法不仅安全，而且允许使用 dd 和十六进制编辑器直接访问底层数据。

• 环境搭建：在 /tmp/zfs-blog-flow 目录下创建多个 512MB 的空文件（如 single.img, r1.img 等）。
• 创建单 vdev 池：创建一个名为 zblog1 的池，挂载点为 /tmp/zfs-blog-flow/single-mnt，关闭 atime 以提升性能。
• 创建 RAIDZ2 池：创建一个名为 zblogR 的池，使用四个文件组成 RAIDZ2 阵列，提供双重奇偶校验冗余。
• 导入池的注意事项：由于池是由普通文件构成的，zpool import 默认可能找不到它们。需要使用 -d 参数指定目录路径，例如 zpool import -d .，以便在导出池后仍能定位到 backing files（支持文件）。

2. “懒惰”的方式：使用 zinject

如果目标仅仅是让文件出现校验和错误，而不关心具体的物理位置，ZFS 提供了 zinject 工具。

• 注入损坏：使用命令 zinject -t data -e checksum -a /path/to/file 可以模拟数据块返回校验和错误。
• 验证与清理：通过 zinject 查看活跃的处理器（handlers），并在测试结束后使用 zinject -c all 清除所有注入规则。
• 局限性：虽然 zinject 在 ZFS 测试套件中被广泛使用且非常有效，但它无法帮助理解数据在磁盘上的具体物理布局，因此对于深入理解 ZFS 机制来说，这种方法“令人不满意”。

3. “教育”的方式：手动追踪文件到硬件

为了真正理解数据在哪里，作者选择手动追踪一个文件从逻辑对象到物理扇区的映射过程。

步骤一：写入测试数据并获取元数据

在单 vdev 池中创建一个包含可识别模式（SINGLE-ZFS-CORRUPTION-DEMO-BLOCK）的 1MB 文件。

• 使用 stat 命令获取文件的 inode、大小和磁盘块占用情况。结果显示该文件占用了 21 个 512 字节的扇区。

步骤二：使用 zdb 解析对象结构

使用 zdb 工具深入查看 ZFS 对象树。

• 关键警告：zdb 的参数必须是 Dataset（数据集），而不是 Pool（池）名称。例如，应使用 zblog1/ 而不是 zblog1，否则查看的是池顶层对象集而非文件系统内的对象。
• 输出解读：zdb -ddddd 输出了详细的对象信息，包括 DVA（Data Virtual Address）指针。
  • 例如，第一级块（L0）的 DVA 为 0:19a00:400。
  • 这表示：vdev ID 为 0，偏移量为 0x19a00，磁盘大小为 0x400 字节。

步骤三：DVA 解码与物理偏移计算

DVA 是 ZFS 表示“数据块住在哪里”的方式。每个 DVA 包含 vdev ID 和偏移量。

• 陷阱：预留空间：ZFS 在每个磁盘的前 4 MiB 保留用于存储 vdev 标签和引导块。因此，DVA 中的偏移量是从这 4 MiB 之后开始计算的。
• 计算公式：
  1. 物理字节偏移 = 0x400000 (4 MiB) + DVA 偏移
  2. 扇区号 = 物理字节偏移 / 512
• 实例计算：
  • DVA 偏移 0x19a00
  • 物理偏移 = 0x400000 + 0x19a00 = 0x419a00
  • 扇区号 = 0x419a00 / 512 = 8397

步骤四：验证与发现“压缩陷阱”

使用 dd 从 single.img 的第 8397 个扇区开始读取，并用 hexdump 查看内容。

• 结果：确实找到了测试字符串 SINGLE-ZFS-CORRUPTION-DEMO-BLOCK。
• 异常现象：数据周围包裹着垃圾数据，文本在一行后截断，且块大小显示为 0x400 字节，而非预期的 128 KiB。
• 原因分析：作者指出，之前的块计数一直在暗示这一点。1 MiB 的文件并没有占据 1 MiB 的物理空间，因为 ZFS 默认启用了压缩（LZ4）。逻辑块大小（Logical Size）与物理块大小（Physical Size）不同。DVA 中的 20000L/400P 明确表示逻辑大小为 0x20000 (128 KiB)，而物理大小仅为 0x400 (1 KiB)。这意味着数据被高度压缩，原本预期的“干净”的大块数据实际上被压缩成了小块，导致直接按逻辑大小读取时出现错位和填充数据。

关键要点

• 安全第一：永远不要在真实的生产磁盘上尝试故意损坏数据。应使用基于文件的模拟池（file-backed pools），并仅在临时环境中操作。
• zinject 的用途：zinject 是模拟损坏和测试 ZFS 自愈能力的标准工具，适用于快速验证错误处理逻辑，但不适用于学习底层存储布局。
• zdb 的参数陷阱：在使用 zdb 时，必须传入 Dataset 路径（如 pool/dataset 或 pool/），而非单纯的 Pool 名称，否则将查询到错误的对象空间。
• DVA 与物理偏移的关系：ZFS 的 DVA 偏移量不包含磁盘前 4 MiB 的预留空间。计算物理扇区时，必须加上 0x400000 (4 MiB) 的偏移，再除以 512。
• 压缩的影响：ZFS 默认启用压缩。逻辑块大小（L）和物理块大小（P）可能差异巨大。在通过 DVA 定位数据时，必须考虑压缩率，否则直接读取物理块可能导致数据截断或误读填充字节。
• 文件模拟池的导入：由普通文件构成的 ZFS 池在导出后，需要使用 zpool import -d <directory> 来指定文件所在目录，以便系统能重新识别并导入池。

意义与影响

这篇文章不仅是一个