目录：
* ZFS 概览
* ZFS 数据完整性和安全性
o 基于事务的写复制操作
o 端对端校验和
* ZFS 可伸缩性
o 128 位体系结构
o 动态元数据
o 文件系统性能
* 资源
ZFS 概览
Sun 最近为 Solaris 10 06/06 操作系统添加了 ZFS，它是对传统 UNIX 文件系统的一次彻底的创新性重新设计。Sun 工程师和开放源代码组织成员汲取市场上一些普遍的最佳做法（如 Network Appliances 快照、VERITAS 基于对象的存储管理、事务及校验和），并糅合自己的想法和专门技术，开发出一种精简紧凑的新方法来设计文件系统。尽管 ZFS 还处于初期阶段，但已对其他 UNIX 供应商产生了如此巨大的影响，以致热衷于开放源代码的生产商纷纷宣布将 ZFS 移植到自己操作系统的计划（请参见 OpenSolaris 站点上的将 ZFS 移植到其他平台）。
凭借 ZFS，Sun 解决了一直困扰其他 UNIX 文件系统的完整性、安全性和可伸缩性以及管理困难等重要问题。本文共分两部分，将剖析 ZFS 在后台的工作以及这些工作如何为企业节省时间和资金。在第一部分中，将讨论数据完整性和安全性模型以及 ZFS 可伸缩性。第二部分将介绍易管理性以及不断增强的 ZFS。
ZFS 数据完整性和安全性
数据完整性和安全性是任何文件系统的最重要的组成部分。保护磁盘信息免受位损坏、无提示损坏乃至恶意或意外篡改是至关重要的。过去，文件系统在应对此类挑战以及提供可靠而精确的数据方面遇到了各种各样的问题。
基于较早技术（如早期版本的 UFS）构建的文件系统在修改使用中的数据时会覆写块。如果在写入过程中出现电源故障，数据便会损坏，文件系统可能会丢失指向重要数据的块指针。为解决这 个问题，fsck 命令会尽力查找脏块，从能够重新连接信息的地方开始重新连接。遗憾的是，fsck 需要查看整个文件系统，所用的时间通常从几秒到几个小时不等，具体取决于该文件系统的大小。对于关键业务系统，每停机一分钟便意味着会损失大量的金钱。为 缩短从电源故障恢复所需的时间，许多文件系统实现（包括较新版本的 UFS）增添了日志记录功能。如果出现损坏日志，仍可调用 fsck 来修复文件系统。但即便是增强版本的 UFS，以及大多数其他有日志记录功能的文件系统，也会因所需开销太大而不记录用户数据。
出于可靠性考虑，人们还曾使用某种类型的卷管理软件来进行磁盘或文件系统镜像。如果发生断电而导致镜像的两半不一致，那么其中一半需要重新同步至另一半， 即使只有一些块有问题也是如此。在重新同步过程中，不但 I/O 性能下降，而且计算机并不总能精确地预测哪个数据副本是未损坏的。有时，它选错了要信任的镜像，因而导致错误数据覆写正确数据。为解决性能问题，有些卷管 理器引入了所谓的脏区域日志记录 (dirty region logging, DRL)。现在，只有断电时正在进行写入的区域才需要重新同步。这种方法对缓解性能问题颇有成效，但仍未解决如何检测哪一半镜像包含有效数据的问题。
ZFS 可以进行基于事务的写复制修改，并始终对文件系统的每个使用中的块进行校验和计算，从而解决了上述问题。
基于事务的写复制操作
ZFS 将文件系统和卷管理器相结合；由于采用了存储池虚拟化，因此文件系统级别的命令并不需要底层物理磁盘的概念。所有高级交互都通过数据管理单元 (data management unit, DMU) 进行，数据管理单元是一个与内存管理单元 (memory management unit, MMU) 类似的概念，它只适用于磁盘而非 RAM。所有通过 DMU 提交的事务都是原子操作，因此数据永远不会处于不一致状态。
除了具备基于事务的文件系统的特征之外，ZFS 只执行写复制操作。这意味着，磁盘中包含使用中数据的块永远不会被修改。更改过的信息将写入备用块，指向使用中数据的块指针只在写入事务完成后移动。在整 个文件系统块结构（自下而上一直到称为超级块 (uberblock) 的顶层块）中都是如此。
如图 1 所示，事务选择未使用的块来写入修改过的数据，并只在完成此操作之后更改上述块所指向的位置。
写复制事务图
图 1：写复制事务
由于指向“正确”数据的指针在整个写入操作完成之前不会移动，因此即使计算机在数据写入过程中发生断电，也不会出现任何损坏。（注意：只有指向数据的指针会移动。）这就消除了计算机意外重新引导时对日志记录文件系统的需求，也不必调用 fsck 或对镜像进行重新同步。
端对端校验和
为避免出现意外的数据损坏，ZFS 提供了基于内存的端对端校验和。大多数具备校验和计算功能的文件系统仅能防止位损坏，原因在于它们使用的是本身一致的块，校验和是与块本身一同存储的。这种情况下，不需要进行外部检查来验证有效性。这种样式的校验和无法捕捉下列各项：
* 虚写，即写入被丢弃
* 误导的读取或写入，即磁盘访问的是错误的块
* 阵列与服务器内存之间的 DMA 奇偶错或来自驱动程序的 DMA 奇偶错，由于校验和验证阵列中的数据
* 驱动程序错误，数据驻留在内核中错误的缓冲区内
* 意外覆写，如交换至实时文件系统
在 ZFS 中，校验和并不存储在块中，而在指向该块的指针旁边，这样一直向上追溯至超级块。只有超级块具有自验证的 SHA-256 校验和。所有块校验和都在服务器内存中完成，因此会捕捉整个树结构中的任何错误，包括上文所述的误导读取和写入、奇偶错、虚写等。过去，CPU 负担会使计算机陷入停顿状态，但现在 CPU 技术和速度的高度发展足以满足即时检查磁盘事务的要求。ZFS 不但能捕捉这些问题，而且在镜像或 RAID-Z 配置环境下数据还可以进行自我修复。（本文第二部分提供了有关 RAID-Z 的更多信息。）
下面是倍受推崇的 Sun 演示之一，它展示了使用 dd 进行数据自我修复，其中 c0t1d0s5 是镜像的一半或 RAID-Z 文件系统：
dd if=/dev/urandom of=/dev/dsk/c0t1d0s5 bs=1024
count=100000
此操作将无用信息写入镜像的一半，但在访问这些块时，ZFS 将执行校验和并识别出该数据是错误数据。随后，ZFS 对另一份数据执行校验和，发现它为有效数据，便对镜像的受损部分的错误块进行重新同步，而不会因为数据损坏而崩溃。在 RAID-Z 配置中，ZFS 按顺序对每个磁盘上的块进行检查，并比较奇偶校验和，直至找到匹配项。找到匹配项后，ZFS 便知已找到有效数据块，继而对所有其他错误磁盘进行修复。重新同步过程对用户而言是完全透明的，用户根本不会发现曾出现过问题。
ZFS 总是在后台通过称为“清理”的进程检查是否有数据损坏。清理磁盘所用的文件系统代码与重新同步、附加镜像、更换磁盘所用的代码相同，从而使整个进程紧密地 集成。管理员也可以运行 zpool scrub 命令强制对整个存储池进行检查。（本文第二部分提供了有关存储池的更多信息。）
#zpool scrub testpool
#zpool status
pool: testpool
state: ONLINE
scrub: scrub completed with 0 errors on Thu Jun 29 12:47:15 2006
config:
NAME STATE READ WRITE CKSUM
testpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s5 ONLINE 0 0 0
c0t1d0s5 ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0
对镜像的受损部分运行上文所述的 dd 命令后，输出类似于以下内容：
#zpool scrub testpool
#zpool status
pool: testpool
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool online' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: scrub completed with 0 errors on Thu Jun 29 12:51:29 2006
config:
NAME STATE READ WRITE CKSUM
testpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s5 ONLINE 0 0 0
c0t1d0s5 ONLINE 0 0 5 2.50K repaired
mirror ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0
输出现在报告：
* 一个设备可能损坏。
* 应用程序未受错误影响，ZFS 已在后台纠正该错误。
* 可能需要更换该设备。
输出还提供了以下信息：
* 如何更换有缺陷的设备
* 如何清除错误
* 一个 URL，指向有关该类型错误的更多信息以及如何进一步执行故障排除并解决问题
* 哪个磁盘片有错误以及成功修复率
运行 zpool online testpool 可清除 CKSUM 列中的错误，但继续显示 c0t1d0s5 已修复。
有关深入探讨，请参阅 Jeff Bonwick 有关 ZFS 镜像重新同步的博客文章。
ZFS 安全性的另一个优点是：它使用 NFSv4/NT 样式的 ACL，其中包括完整的允许/拒绝语义和继承。这些基于 17 种不同属性的访问控制极为精细。
ZFS 可伸缩性
虽然数据安全性和完整性极为重要，但一个文件系统也必须运行良好，能够经受时间的考验，否则也没有多大用处。ZFS 的设计者通过使用 128 位体系结构并将所有元数据设置为动态元数据，消除或极大降低了现代文件系统所施加的限制。此外，ZFS 还实现了数据管道传输、动态块大小调整、智能预取、动态条带化和内置压缩，以便提高性能。
128 位体系结构
当前行业趋势显示，每九个月到一年磁盘驱动器的容量就会增长约一倍。如果这种趋势持续下去，大约 10 到 15 年内文件系统将要求 64 位寻址能力。ZFS 设计者基于长远考虑，实现了 128 位文件系统，而没有针对 64 位要求制定规划。这意味着 ZFS 可提供的容量相当于目前 64 位文件系统的 160 亿倍以上。我们引用 ZFS 首席设计师 Jeff Bonwick 在 ZFS: the last word in file systems 一文中所说的一句话，那就是 "Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans."（填满 128 位文件系统的话，会超出基于地球的存储量程限制。想用完 128 位存储池，得先把大海蒸发掉才行。）Jeff 还在其有关 128 位存储的博客文章中讨论了上面这句话依据的数学理论。既然目前尚无技术能够在大众市场营造出这种功效，那么在一段时间内我们仍是安全的。
动态元数据
ZFS 不但是 128 位，其元数据也是百分之百动态的。因此，创建新的存储池和文件系统的速度极快。只有 1% 到 2% 的磁盘写入是元数据，这样就大大节省了初始开销。例如，没有静态 inode，因此唯一的限制是放在存储池磁盘中的 inode 的数量。
128 位体系结构也意味着对文件和目录等的数量没有实际限制。下面列出了一些理论限制，如果您能想象得出受限范围，那会让人大吃一惊的：
* 在任何文件系统中快照数不能超过 248
* 在任何单个文件系统中文件数不能超过 248
* 文件系统不能超过 16 百亿亿字节
* 文件不能超过 16 百亿亿字节
* 属性不能超过 16 百亿亿字节
* 存储池不能超过 3x1023 千万亿字节
* 一个文件中的属性数不能超过 248
* 一个目录中的文件数不能超过 248
* 一个存储池中的设备数不能超过 264
* 每个系统的存储池数不能超过 264
* 每个存储池的文件系统数不能超过 264
文件系统性能
与传统文件系统相比，ZFS 的基础设计提供了大量性能增强功能。在启动器方面，ZFS 使用了管道化 I/O 引擎，它在概念上与 CPU 管道类似。管道作用于 I/O 相互依赖性，可以根据相关优先级和最终期限进行排序。该管道提供记分板、优先级、最终期限调度、失序发射和 I/O 聚合。ZFS 还实现了一种智能预取算法，该算法可识别线性或算法访问模式，并预测要预取的下一个块。
只要可能，ZFS 就会使用并发性来提高速度。文件系统支持对同一个文件并行读写，还支持并行常量时间目录操作，锁定策略是可伸缩的且运行速度很快。此外，可以按任意顺序在 任何给定事务中执行操作，因此 DMU 对读写进行批处理以优化磁盘工作。由于事务以写复制方式进行，因此可以为新数据选择连续块，而不是随机访问磁盘。这样，磁盘的运行速度便可以达到或接近盘 片的速度。ZFS 还自动将块大小（从 512 字节到 128K）与工作负荷进行匹配，以获得最佳性能。
ZFS 可以对所有可用设备上的数据进行动态条带化处理。向条带中添加另一个磁盘或分片时，ZFS 会自动合并新的空间，并对写入条带化进行重新平衡以利用新添加的空间。如果某个设备因错误而进入降级模式，ZFS 也会尽力不对该设备执行写入操作，而是将负载分摊到其他设备。
最后，ZFS 还为每个文件系统提供了内置数据压缩。压缩不但降低了磁盘空间使用量，还将必要的 I/O 量减少了二至三倍。因此，启用压缩实际上能够提高某些 I/O 密集型工作负荷的运行速度，但 CPU 密集型工作负荷则不行。
有关 ZFS 基准测试的一些信息，请参考其他一些网页：
* Bill Moore 有关 ZFS 基准测试的博客文章
* Roch 有关一天内与 UFS 相比 ZFS 基准测试的博客文章
* James Dickens 有关比较 UFS 区域和 ZFS 区域的博客文章
在第 2 部分中，将介绍更多 ZFS 实际操作：创建存储池和文件系统、设置文件系统参数以及数据快照和克隆。另外，还会重点介绍一些 ZFS 开发方面更有趣的功能。
资源
* ZFS－Sun 的最新文件系统（第 2 部分：易于管理且功能不断增强）
* 关于 ZFS 的 Solaris 10 OS 更新 06/06
* 下载 Solaris Express
* OpenSolaris Community: ZFS
* OpenSolaris ZFS 入门页
* ZFS Learning Center
* 移植 ZFS
* Jeff Bonwick 有关 ZFS 镜像重新同步的博客文章
* Jeff Bonwick 另一篇博客文章：You say zeta, I say zetta
* ZFS: the last word in file systems
* Jeff Bonwick 有关选择 128 位存储体系结构的博客文章
* Bill Moore 有关 ZFS 基准测试的博客文章
* Roch 有关一天内与 UFS 相比 ZFS 基准测试的博客文章
* James Dickens 有关比较 UFS 区域和 ZFS 区域的博客文章
* ZFS 概览
* ZFS 数据完整性和安全性
o 基于事务的写复制操作
o 端对端校验和
* ZFS 可伸缩性
o 128 位体系结构
o 动态元数据
o 文件系统性能
* 资源
ZFS 概览
Sun 最近为 Solaris 10 06/06 操作系统添加了 ZFS，它是对传统 UNIX 文件系统的一次彻底的创新性重新设计。Sun 工程师和开放源代码组织成员汲取市场上一些普遍的最佳做法（如 Network Appliances 快照、VERITAS 基于对象的存储管理、事务及校验和），并糅合自己的想法和专门技术，开发出一种精简紧凑的新方法来设计文件系统。尽管 ZFS 还处于初期阶段，但已对其他 UNIX 供应商产生了如此巨大的影响，以致热衷于开放源代码的生产商纷纷宣布将 ZFS 移植到自己操作系统的计划（请参见 OpenSolaris 站点上的将 ZFS 移植到其他平台）。
凭借 ZFS，Sun 解决了一直困扰其他 UNIX 文件系统的完整性、安全性和可伸缩性以及管理困难等重要问题。本文共分两部分，将剖析 ZFS 在后台的工作以及这些工作如何为企业节省时间和资金。在第一部分中，将讨论数据完整性和安全性模型以及 ZFS 可伸缩性。第二部分将介绍易管理性以及不断增强的 ZFS。
ZFS 数据完整性和安全性
数据完整性和安全性是任何文件系统的最重要的组成部分。保护磁盘信息免受位损坏、无提示损坏乃至恶意或意外篡改是至关重要的。过去，文件系统在应对此类挑战以及提供可靠而精确的数据方面遇到了各种各样的问题。
基于较早技术（如早期版本的 UFS）构建的文件系统在修改使用中的数据时会覆写块。如果在写入过程中出现电源故障，数据便会损坏，文件系统可能会丢失指向重要数据的块指针。为解决这 个问题，fsck 命令会尽力查找脏块，从能够重新连接信息的地方开始重新连接。遗憾的是，fsck 需要查看整个文件系统，所用的时间通常从几秒到几个小时不等，具体取决于该文件系统的大小。对于关键业务系统，每停机一分钟便意味着会损失大量的金钱。为 缩短从电源故障恢复所需的时间，许多文件系统实现（包括较新版本的 UFS）增添了日志记录功能。如果出现损坏日志，仍可调用 fsck 来修复文件系统。但即便是增强版本的 UFS，以及大多数其他有日志记录功能的文件系统，也会因所需开销太大而不记录用户数据。
出于可靠性考虑，人们还曾使用某种类型的卷管理软件来进行磁盘或文件系统镜像。如果发生断电而导致镜像的两半不一致，那么其中一半需要重新同步至另一半， 即使只有一些块有问题也是如此。在重新同步过程中，不但 I/O 性能下降，而且计算机并不总能精确地预测哪个数据副本是未损坏的。有时，它选错了要信任的镜像，因而导致错误数据覆写正确数据。为解决性能问题，有些卷管 理器引入了所谓的脏区域日志记录 (dirty region logging, DRL)。现在，只有断电时正在进行写入的区域才需要重新同步。这种方法对缓解性能问题颇有成效，但仍未解决如何检测哪一半镜像包含有效数据的问题。
ZFS 可以进行基于事务的写复制修改，并始终对文件系统的每个使用中的块进行校验和计算，从而解决了上述问题。
基于事务的写复制操作
ZFS 将文件系统和卷管理器相结合；由于采用了存储池虚拟化，因此文件系统级别的命令并不需要底层物理磁盘的概念。所有高级交互都通过数据管理单元 (data management unit, DMU) 进行，数据管理单元是一个与内存管理单元 (memory management unit, MMU) 类似的概念，它只适用于磁盘而非 RAM。所有通过 DMU 提交的事务都是原子操作，因此数据永远不会处于不一致状态。
除了具备基于事务的文件系统的特征之外，ZFS 只执行写复制操作。这意味着，磁盘中包含使用中数据的块永远不会被修改。更改过的信息将写入备用块，指向使用中数据的块指针只在写入事务完成后移动。在整 个文件系统块结构（自下而上一直到称为超级块 (uberblock) 的顶层块）中都是如此。
如图 1 所示，事务选择未使用的块来写入修改过的数据，并只在完成此操作之后更改上述块所指向的位置。
写复制事务图
图 1：写复制事务
由于指向“正确”数据的指针在整个写入操作完成之前不会移动，因此即使计算机在数据写入过程中发生断电，也不会出现任何损坏。（注意：只有指向数据的指针会移动。）这就消除了计算机意外重新引导时对日志记录文件系统的需求，也不必调用 fsck 或对镜像进行重新同步。
端对端校验和
为避免出现意外的数据损坏，ZFS 提供了基于内存的端对端校验和。大多数具备校验和计算功能的文件系统仅能防止位损坏，原因在于它们使用的是本身一致的块，校验和是与块本身一同存储的。这种情况下，不需要进行外部检查来验证有效性。这种样式的校验和无法捕捉下列各项：
* 虚写，即写入被丢弃
* 误导的读取或写入，即磁盘访问的是错误的块
* 阵列与服务器内存之间的 DMA 奇偶错或来自驱动程序的 DMA 奇偶错，由于校验和验证阵列中的数据
* 驱动程序错误，数据驻留在内核中错误的缓冲区内
* 意外覆写，如交换至实时文件系统
在 ZFS 中，校验和并不存储在块中，而在指向该块的指针旁边，这样一直向上追溯至超级块。只有超级块具有自验证的 SHA-256 校验和。所有块校验和都在服务器内存中完成，因此会捕捉整个树结构中的任何错误，包括上文所述的误导读取和写入、奇偶错、虚写等。过去，CPU 负担会使计算机陷入停顿状态，但现在 CPU 技术和速度的高度发展足以满足即时检查磁盘事务的要求。ZFS 不但能捕捉这些问题，而且在镜像或 RAID-Z 配置环境下数据还可以进行自我修复。（本文第二部分提供了有关 RAID-Z 的更多信息。）
下面是倍受推崇的 Sun 演示之一，它展示了使用 dd 进行数据自我修复，其中 c0t1d0s5 是镜像的一半或 RAID-Z 文件系统：
dd if=/dev/urandom of=/dev/dsk/c0t1d0s5 bs=1024
count=100000
此操作将无用信息写入镜像的一半，但在访问这些块时，ZFS 将执行校验和并识别出该数据是错误数据。随后，ZFS 对另一份数据执行校验和，发现它为有效数据，便对镜像的受损部分的错误块进行重新同步，而不会因为数据损坏而崩溃。在 RAID-Z 配置中，ZFS 按顺序对每个磁盘上的块进行检查，并比较奇偶校验和，直至找到匹配项。找到匹配项后，ZFS 便知已找到有效数据块，继而对所有其他错误磁盘进行修复。重新同步过程对用户而言是完全透明的，用户根本不会发现曾出现过问题。
ZFS 总是在后台通过称为“清理”的进程检查是否有数据损坏。清理磁盘所用的文件系统代码与重新同步、附加镜像、更换磁盘所用的代码相同，从而使整个进程紧密地 集成。管理员也可以运行 zpool scrub 命令强制对整个存储池进行检查。（本文第二部分提供了有关存储池的更多信息。）
#zpool scrub testpool
#zpool status
pool: testpool
state: ONLINE
scrub: scrub completed with 0 errors on Thu Jun 29 12:47:15 2006
config:
NAME STATE READ WRITE CKSUM
testpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s5 ONLINE 0 0 0
c0t1d0s5 ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0
对镜像的受损部分运行上文所述的 dd 命令后，输出类似于以下内容：
#zpool scrub testpool
#zpool status
pool: testpool
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool online' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: scrub completed with 0 errors on Thu Jun 29 12:51:29 2006
config:
NAME STATE READ WRITE CKSUM
testpool ONLINE 0 0 0
mirror ONLINE 0 0 0
c0t0d0s5 ONLINE 0 0 0
c0t1d0s5 ONLINE 0 0 5 2.50K repaired
mirror ONLINE 0 0 0
c0t0d0s6 ONLINE 0 0 0
c0t1d0s6 ONLINE 0 0 0
输出现在报告：
* 一个设备可能损坏。
* 应用程序未受错误影响，ZFS 已在后台纠正该错误。
* 可能需要更换该设备。
输出还提供了以下信息：
* 如何更换有缺陷的设备
* 如何清除错误
* 一个 URL，指向有关该类型错误的更多信息以及如何进一步执行故障排除并解决问题
* 哪个磁盘片有错误以及成功修复率
运行 zpool online testpool 可清除 CKSUM 列中的错误，但继续显示 c0t1d0s5 已修复。
有关深入探讨，请参阅 Jeff Bonwick 有关 ZFS 镜像重新同步的博客文章。
ZFS 安全性的另一个优点是：它使用 NFSv4/NT 样式的 ACL，其中包括完整的允许/拒绝语义和继承。这些基于 17 种不同属性的访问控制极为精细。
ZFS 可伸缩性
虽然数据安全性和完整性极为重要，但一个文件系统也必须运行良好，能够经受时间的考验，否则也没有多大用处。ZFS 的设计者通过使用 128 位体系结构并将所有元数据设置为动态元数据，消除或极大降低了现代文件系统所施加的限制。此外，ZFS 还实现了数据管道传输、动态块大小调整、智能预取、动态条带化和内置压缩，以便提高性能。
128 位体系结构
当前行业趋势显示，每九个月到一年磁盘驱动器的容量就会增长约一倍。如果这种趋势持续下去，大约 10 到 15 年内文件系统将要求 64 位寻址能力。ZFS 设计者基于长远考虑，实现了 128 位文件系统，而没有针对 64 位要求制定规划。这意味着 ZFS 可提供的容量相当于目前 64 位文件系统的 160 亿倍以上。我们引用 ZFS 首席设计师 Jeff Bonwick 在 ZFS: the last word in file systems 一文中所说的一句话，那就是 "Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans."（填满 128 位文件系统的话，会超出基于地球的存储量程限制。想用完 128 位存储池，得先把大海蒸发掉才行。）Jeff 还在其有关 128 位存储的博客文章中讨论了上面这句话依据的数学理论。既然目前尚无技术能够在大众市场营造出这种功效，那么在一段时间内我们仍是安全的。
动态元数据
ZFS 不但是 128 位，其元数据也是百分之百动态的。因此，创建新的存储池和文件系统的速度极快。只有 1% 到 2% 的磁盘写入是元数据，这样就大大节省了初始开销。例如，没有静态 inode，因此唯一的限制是放在存储池磁盘中的 inode 的数量。
128 位体系结构也意味着对文件和目录等的数量没有实际限制。下面列出了一些理论限制，如果您能想象得出受限范围，那会让人大吃一惊的：
* 在任何文件系统中快照数不能超过 248
* 在任何单个文件系统中文件数不能超过 248
* 文件系统不能超过 16 百亿亿字节
* 文件不能超过 16 百亿亿字节
* 属性不能超过 16 百亿亿字节
* 存储池不能超过 3x1023 千万亿字节
* 一个文件中的属性数不能超过 248
* 一个目录中的文件数不能超过 248
* 一个存储池中的设备数不能超过 264
* 每个系统的存储池数不能超过 264
* 每个存储池的文件系统数不能超过 264
文件系统性能
与传统文件系统相比，ZFS 的基础设计提供了大量性能增强功能。在启动器方面，ZFS 使用了管道化 I/O 引擎，它在概念上与 CPU 管道类似。管道作用于 I/O 相互依赖性，可以根据相关优先级和最终期限进行排序。该管道提供记分板、优先级、最终期限调度、失序发射和 I/O 聚合。ZFS 还实现了一种智能预取算法，该算法可识别线性或算法访问模式，并预测要预取的下一个块。
只要可能，ZFS 就会使用并发性来提高速度。文件系统支持对同一个文件并行读写，还支持并行常量时间目录操作，锁定策略是可伸缩的且运行速度很快。此外，可以按任意顺序在 任何给定事务中执行操作，因此 DMU 对读写进行批处理以优化磁盘工作。由于事务以写复制方式进行，因此可以为新数据选择连续块，而不是随机访问磁盘。这样，磁盘的运行速度便可以达到或接近盘 片的速度。ZFS 还自动将块大小（从 512 字节到 128K）与工作负荷进行匹配，以获得最佳性能。
ZFS 可以对所有可用设备上的数据进行动态条带化处理。向条带中添加另一个磁盘或分片时，ZFS 会自动合并新的空间，并对写入条带化进行重新平衡以利用新添加的空间。如果某个设备因错误而进入降级模式，ZFS 也会尽力不对该设备执行写入操作，而是将负载分摊到其他设备。
最后，ZFS 还为每个文件系统提供了内置数据压缩。压缩不但降低了磁盘空间使用量，还将必要的 I/O 量减少了二至三倍。因此，启用压缩实际上能够提高某些 I/O 密集型工作负荷的运行速度，但 CPU 密集型工作负荷则不行。
有关 ZFS 基准测试的一些信息，请参考其他一些网页：
* Bill Moore 有关 ZFS 基准测试的博客文章
* Roch 有关一天内与 UFS 相比 ZFS 基准测试的博客文章
* James Dickens 有关比较 UFS 区域和 ZFS 区域的博客文章
在第 2 部分中，将介绍更多 ZFS 实际操作：创建存储池和文件系统、设置文件系统参数以及数据快照和克隆。另外，还会重点介绍一些 ZFS 开发方面更有趣的功能。
资源
* ZFS－Sun 的最新文件系统（第 2 部分：易于管理且功能不断增强）
* 关于 ZFS 的 Solaris 10 OS 更新 06/06
* 下载 Solaris Express
* OpenSolaris Community: ZFS
* OpenSolaris ZFS 入门页
* ZFS Learning Center
* 移植 ZFS
* Jeff Bonwick 有关 ZFS 镜像重新同步的博客文章
* Jeff Bonwick 另一篇博客文章：You say zeta, I say zetta
* ZFS: the last word in file systems
* Jeff Bonwick 有关选择 128 位存储体系结构的博客文章
* Bill Moore 有关 ZFS 基准测试的博客文章
* Roch 有关一天内与 UFS 相比 ZFS 基准测试的博客文章
* James Dickens 有关比较 UFS 区域和 ZFS 区域的博客文章
扫一扫
403
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
