> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20180304-zhuo-mian-bi-ji-ben/zfs-2018-and-onward.md).

# ZFS 2018 及展望

作者：**Allan Jude**

2018 年对 FreeBSD 和 OpenZFS 都将是重要的一年。OpenZFS 是来自 IllumOS、FreeBSD、Linux、Mac OS X、众多行业厂商以及其他若干项目的开发者的协作组织，旨在维护和推进 Sun 的 ZFS 文件系统的开源版本。

## 改进的存储池导入

* **2018Q1**

新的补丁集改变了存储池的导入方式，使其更少依赖系统上的配置数据。导入时使用系统上可能已过时的配置来定位存储池，并以只读方式部分打开它。然后加载正确的盘上配置。这减少了可能阻止存储池导入的错误数量。

补丁还改进了错误消息，更好地解释存储池无法导入时出了什么问题。此外，它新增了一项长期寻求的功能：可以导入缺失顶级设备的存储池。这种导入是只读的，因为缺失的数据太多，无法正常使用存储池，但部分数据可能可以恢复。

## ZFS 设备迁移

* **2018Q1**

从存储池中移除多余 VDEV 的能力。位于 stripe（非冗余）或镜像 VDEV 上的数据可以“迁移”，移动到将保留的设备上，从而允许选定的 VDEV 从存储池中移除。这通过间接表实现：从被移除设备上来的块范围被重映射到另一个设备。此功能不适用于 RAID-Z VDEV，目前也不计划支持。

## ZFS RAID-Z 扩容

* **2018Q4**

向现有 RAID-Z VDEV 添加新硬盘以扩大其容量而不改变冗余级别的能力。例如，由 6 块盘组成的 RAID-Z2 可以扩展为 7 块盘，从而增加可用空间。实现方式是在各盘之间重新流淌（reflow）数据，从而不改变单个块在 VDEV 起始处的偏移。新硬盘会作为右侧的新列出现，数据被重新安置以维持其在 VDEV 内的偏移。类似于通过加宽段落来重新流淌文本，而不改变文字顺序。最终结果是新空间全部出现在硬盘末尾，且没有碎片。遗憾的是，VDEV 内已有的碎片会被保留。未来或许可以用类似方案提升冗余级别（通过添加一块盘把 RAID-Z1 升级为 RAID-Z2），但这不属于当前项目规范。

## ZFS ZStandard 压缩

* **2018Q2**

此项目将 Facebook 的新型 Zstandard 压缩算法引入 ZFS，作为可选的透明压缩算法。这一新算法旨在提供与 gzip 相当甚至更好的压缩比，但速度快许多倍。Zstandard 由 LZ4 的作者 Yann Collet 开发，LZ4 多年来一直是 OpenZFS 的默认压缩算法，ZSTD 提供了压缩与性能之间更诱人的折中。虽然不如 LZ4 快，但它能实现更高的压缩比，且仍能以少量 CPU 核心使许多机械硬盘饱和。它还提供更强的控制力，有 19 个压缩级别可选，每个数据集都可配置最优压缩量。

## ZFS 自适应压缩

* **调查中**

自适应压缩功能仍在进行初步调查，但若实现，ZFS 将根据等待压缩和写入的脏数据量，在数据写入时自动调整压缩比上下浮动。系统空闲时，可分配更多 CPU 时间压缩数据；但当压缩吞吐量跟不上写入需求时，压缩级别会降低以避免成为瓶颈。

## FreeBSD ZFS 备件与故障管理

* **2019Q1**

对 FreeBSD 从 ZFS 启动方式的改进，使其更贴近 ZFS 最初的设计。这些更改将消除对 `freebsd-boot` 分区的需求，并允许分区表由 ZFS 而非 GEOM 创建，从而使 `zfsd` 和 ZFS 故障管理框架能自动将替换设备附加到存储池并开始重建（resilver）操作，而无需管理员介入。

目前只有当整个设备专用于 ZFS 且没有分区表时才可能如此。要从该设备启动，必须存在 `freebsd-boot` 或 EFI ESP 分区。在 ZFS 最初设计中，有一块区域专用于存储遗留 BIOS 引导代码，但在 FreeBSD 下仅当硬盘以 MBR 分区时才使用它。在其他 ZFS 实现中，如果整块硬盘用于 ZFS，会创建一个基本分区表，将整个设备标记为单个 ZFS 分区。ZFS 移植到 FreeBSD 时，标志 `whole_disk` 被字面理解，ZFS 直接使用原始硬盘。通过对上游已提议的、在 ZFS whole\_disk 布局中创建 EFI 分区的增强，加上一些小的更改，FreeBSD 也能以同样方式工作。这意味着热备盘和故障后更换的硬盘可以自动标记、分区并加入存储池，无需像现在这样需要人工介入。

## ZFS 持久化 L2ARC

* **2018Q3**

ZFS L2ARC 提供二级缓存，允许 SSD 或 NVMe 等高速设备在 ARC（位于 RAM）和主存储池之间提供另一层缓存。当拥有大于工作集的主内存不经济或不可行时，这对于获得所需的性能水平极为重要。L2ARC 依赖 ARC 中的头部信息指向存储在 L2ARC 中的数据。ARC 不持久化，因为它存储在主内存中，所以系统重启时 L2ARC 内容会被孤立。启动时 L2ARC 被视为空，随缓存升温逐渐被重新填充。在缓存重新预热之前，这可能导致显著的性能损失。这通过在 L2ARC 冷时增加填充速度的配置选项得到部分缓解。新的持久化 L2ARC 功能在 L2ARC 上保留日志记录，可在系统启动后重新加载。系统在线后，会异步重建指向 L2ARC 数据的 ARC 头部，使 L2ARC 内容能在重启后保持。虽然它们不是立即可用，但系统达到热缓存状态的速度比没有此功能时快得多，且对 L2ARC 设备的损耗更小。

## ZFS 顺序重建（Resilver）

* **待集成**

ZFS 的一个优势在于文件系统和卷管理器合二为一，ZFS 知道硬盘上哪些字节正在使用，哪些未使用。只填满 1/3 的硬盘只需要重建这 1/3 数据，而不像典型硬件 RAID 那样重建整个硬盘内容。然而，要实现这一优势，ZFS 按对象在元数据中出现的顺序扫描内容。这可能导致大量随机读写，性能远差于顺序读写。这一对重建过程的改进将扫描元数据并构建一棵需重建块的范围树。当此树达到配置的大小限制时，重建树中最大的连续块范围，然后元数据扫描继续，直到范围树再次填满。这种方法确保重建 I/O 以大段连续范围进行，性能好得多。

## ZFS 重建预取改进

* **设计评审**

这套改进旨在以与顺序重建工作互补的不同方式提升重建性能。新的预取器更接近深度优先搜索，而不仅是工作在 scrub 之前并在每个子树末尾停顿。新系统中，一个按需读取完成会触发下一批预取操作，保持 I/O 队列满。配置防止同时有多于两个 scrub 预取 I/O 未完成，避免预取延迟实际的 scrub 操作。

## ZFS Ashift 策略

* **设计阶段**

此项工作的目标是支持时间可变的几何参数。允许旧式 512 字节扇区硬盘被新式 4096 字节扇区硬盘替换，而不会因执行子扇区写入带来性能损失。即使现在，许多硬盘已是 4Kn（4k 原生），并会拒绝执行子扇区 I/O。此功能允许设置分配策略，使未来所有分配至少为 4k，避免性能损失。

## ZFS 空间映射日志

* **设计评审**

ZFS 使用称为空间映射（spacemap）的数据结构跟踪硬盘上哪些空间可供未来分配。空间映射有内存中和盘上两种表示。通常一次只加载少量空间映射，分配从这些映射中进行。在严重碎片化下，系统可能花费大量时间寻找可分配的空闲空间。现有空间映射直方图功能有助于缓解此问题。空间映射日志功能将通过将分配和释放操作写入只追加日志来提升分配性能，当日志超过配置大小时再合并到传统空间映射数据结构中。崩溃时，会加载上一个空间映射，然后重放空间映射日志中指定的更改以更新到最新状态。

## 原生数据与元数据加密

* **代码评审**

原生加密支持基于与 Oracle 专有 ZFS 类似但不兼容的设计。实现允许若干有用功能，包括认证加密，意味着不仅保护数据的隐私，还保护其完整性。OpenZFS 实现允许每个数据集使用不同密钥加密，或从父数据集继承密钥。密钥可按需加载和卸载，因此数据可以真正“静止”，通过卸载数据集和加密密钥来提供更有意义的保护。另一个有用功能是校验和拆分为明文的传统校验和与来自加密算法的认证数据，从而同时保护明文和密文。这意味着 ZFS 可以检测任一形式的损坏或篡改，但也意味着即使加密密钥未加载，scrub 和重建操作也能进行。还意味着加密数据集可以以加密形式复制，使接收方在没有正确密钥的情况下无法读取。

## Windows 移植

* **早期预览**

最后一项主要图个乐。OpenZFS-on-OS-X 项目背后的一些人想知道把 OpenZFS 移植到 Microsoft Windows 需要多少工作。事实证明，并非你想象的那么不可能。你可以访问 GitHub 页面 <https://github.com/openzfsonwindows/ZFSin> 了解更多。

## 结论

OpenZFS 自 2010 年与 OpenSolaris 分道扬镳、2013 年正式成立 OpenZFS 组织以来，已走过漫长道路。OpenZFS 如今超过 50% 的代码是新增或从原始 OpenSolaris 代码替换而来。OpenZFS 继续引领文件系统发展，且随着更多项目和厂商加入，这一节奏只会加快。

你可以在 OpenZFS Developers Summit 2017 Wiki 页面了解许多这些以及其他最近添加和即将推出的 OpenZFS 特性，其中包含每场演讲的幻灯片和视频：<http://open-zfs.org/wiki/OpenZFS_Developer_Summit_2017>。•

***

**ALLAN JUDE** 是 ScaleEngine Inc.（一家视频流内容分发网络）的运营副总裁，他在其中广泛使用 FreeBSD 上的 ZFS。Allan 是 FreeBSD src 和 doc committer，于 2016 年夏当选 FreeBSD 核心团队成员。他也是每周视频播客 BSDNow\.tv（与 Benedict Reuschling 主持）的主持人，并与 Michael W Lucas 合著了 FreeBSD Mastery: ZFS 和 FreeBSD Mastery: Advanced ZFS。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20180304-zhuo-mian-bi-ji-ben/zfs-2018-and-onward.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
