Solaris 10 最新版：使用ZFS的十条理由 - ZFS特性介绍
上个月，Sun Microsystems公司正式发布ZFS（Zettabyte File
System）文件系统。ZFS是第一个128位的文件系统，同时ZFS又被Sun
Microsystems称作史上最后一个文件系统。因为这个文件系统含有多项创新技术，不仅成功地解决现有文件系统的问题和陋习，而且前瞻性地考量了未
来对存储空间的需求，单个文件系统可以达到256 quadrillion（264） Zettabytes（221）。
ZFS不仅符合POSIX文件系统的标准，而且提供了许多高级功能比如：Quota(配额)，Reservation(预留)，
Compression(压缩)，
Snapshot(快照)，Clone（克隆）等。如果你还在坚持使用现有32位或者64位的文件系统，如果你还在“痛并不快乐着”地用着各式各样的
Volume Manager，那就很值得看看这里列出的使用ZFS的十条理由。
1. 再也不需要fsck， scandisk O-/^MypP^
不管你是在用Linux，UNIX还是Windows，相信大家都有过类似的体会：当系统意外断电或者非法关机，系统重起后发现文件系统有
inconsistent的问题，这时 候就需要fsck或者scandisk
来修复，这段时间是非常耗时而且最后不一定能够修复成功。更糟糕的是，如果这是一台服务器需要做fsck的时候，只能offline（下线），而且现有应
用往往都是大硬盘，相应fsck修 复时间也很长，这对许多使用该服务器的用户来说几乎不能忍受的。 iIDkM];
而使用ZFS后大家可以彻底抛弃fsck这种工具，因为ZFS是一个基于COW（Copy on
Write）机制的文件系统。COW是不会对硬盘上现有的文件进行重写，保证所有硬盘上的文件都是有效的。所以不会有这种inconsistent的概
念，自然就不需要这种工具了。
2. 管理简单
ZFS作为一个全新的文件系统，全面抛弃传统File System + Volume Manager +
Storage的架构，所有的存储设备是通过ZFS Pool进行管理，只要把各种存储设备加 入同一个ZFS Pool，大家就可以轻松的在这个ZFS
Pool管理配置文件系统。大家再也不用牢记各种专业概念，各种命令newfs， metinit及各种Volume
Manager的用法。在ZFS中我们只需要两个命令，zpool(针 对ZFS
Pool管理)和zfs(针对ZFS文件系统的管理)，就可以轻松管理128位的文件系统。举个例子，我们经常会遇到系统数据增长过
快，现有存储容量不够，需要添加硬盘，如果依照传统的Volume Manager管理方式，那我
们需要预先要考虑很多现有因素，还要预先根据应用计算出需要配置的各种参数。在ZFS情况下，我们的系统管理员可以彻底解放，再也不需要这种人为的复杂
考虑和计算，我们可以把这些交给ZFS，因为ZFS Pool会自动调节，动态适应需求。我们只需一个简单的命令为 这个ZFS
Pool加入新的硬盘就可以了：
zpool add zfs_pool mirror c4t0d0 c5t0d0
基于这个动态调节的ZFS Pool之上的所有的文件系统就可以立即使用到这个新的硬盘，并且会自动的选择最优化的参数。
而且ZFS同时也提供图形化的管理界面，下面是一个ZFS图形化管理的一个截屏：
e3P&3�|z
3. 没有任何容量限制
ZFS（Zettabyte File
System）文件系统就如其名字所预示，可以提供真正的海量存储，在现实中几乎不可能遇到容量问题。在现有的64位kernel（内
核）下，它可以容纳达到16 Exabytes(264)大小的单个文件，可以使用264个存储设备，可以创建264个文件系统。
4. 完全保证 数据 的正确和完整
由于ZFS所有的数据操作都是基 于Transaction（事务），一组相应的操作会被ZFS解
析为一个事务操作，事务的操作就代表着一组操作要么一起失败，要么一起成功。而且如前所说，ZFS对 所有的操作是基于COW（Copy on
Write）， 从而保证设备上的数 据始终都是有效的，再也不会因为系统崩溃或者意外掉电导致数据文件的inconsistent。
还有一种潜在威胁 数据的可能是来自于硬件设备的问题，比如磁
盘，RAID卡的硬件问题或者驱动bug。现有文件系统通常遇到这个问题，往往只是简单的把错误数据直接交给上层应用，通常我们把这个问题称作
Silent Data Corruption。而在ZFS中，对所有数据不管是用户数据还是文件系统自身的metadata数
据都进行256位的Checksum（校 验），当ZFS在提交数据时会进行校验，彻底杜绝这种Silent Data Corruption情况。
5. 提供优异 性能和扩展性
和传统File System + Volume Manager + Storage架构不同，ZFS则是直接基于存储设备提供所有的功能，因此有自己独有的创新特性，性能自然非比寻常。
Dynamic Striping vs. Static Striping
由于ZFS是基于COW和一个全局动态的ZFS Pool，任何一次写 操作，都是对一块新数据块（Block）的一次写操作。ZFS从ZFS
Pool中动态挑选出一个最优的设备，并且以一个transaction（事
务）线性写入，充分有效地利用了现有设备的带宽，我们把这个特性称为Dynamic Striping。而相对应的Static
Striping则是传统文件系统所使用的方式，Static Striping需要管理员预先对这组Stripe进行正确地计算人为
设置，而且如果加入新的设备则需要再次人为的计算和设置，更为严重的是如果人为计算错误，则会直接影响系统的性能。而在使用Dynamic
Striping这种特性之后，我们根本不需要人为介入，ZFS会自动调整，智能的为你 提供最佳的设备，最快的操作方式。 mNjIc^zH
<}Wy[e5o
支持多种 大小的数据块（Multiple Block Size）
ZFS支持多种大小的数据块定义，从512字节到1M字节。和传统文件系统往往都是固定大小数据块不同，ZFS则是可以动态的根据不同 大小的文件进行计算，动态的选择最佳的数据块。
因为不同大小数据
块，直接影响到实际使用硬盘容量和读取速度。如果使用较小的数据块，存储文件所导致的碎片则较少，读写小文件更快一些，但是会导致需要创建更多的
metadata，读写大文件则会更费时。如果使用较大的数据块，使用的metadata较少，更利于读写大文件，但是会导致更多的碎片。ZFS根据实际
调查现有文件使 用的情况，分析出一个选择数据块大小的算法，动态的根据实际文件大小确定最佳的数据块。所以ZFS是
非常智能的，在不需要系统管理员介入，就可以得到一个自我调优的结果。当然ZFS也支持用户对单个文件或者整个文件系统
所使用的数据块大小的自定义设置。
智能预读取（Intelligent Prefetch）
多数的操作系统都
有这种将数据预先读取的功能，而ZFS则是建立在文件系统上直接提供的一种更加智能的数据预读取功能。它不仅可以智能地识别出多种读取模式， 进
行提前读取数据，而且可以对每个读取数据流进行这种预读取智能识别，这个对许多流媒体提供者来说是件非常好的事情。
在扩展性上，和现有文件系统多是基于一个受限的静态模型不同，ZFS是采用ZFS Pool这个动态概念，它的metadata也是动态，并且读写操作都是可并行的，并且具有优先级概念，所以即使在大数据量，多设备的情况下仍可以保证性能的线性增长。
6. 自我修复功能
ZFS Mirror 和 RAID-Z
传统的硬盘Mirror及RAID 4，RAID 5阵列方式都会遇到前面提到过的问题：Silent Data
Corruption。如果发生了某块硬盘物理问题导致数据错误，现有的Mirror，包括RAID 4，RAID
5阵列会默默地把这个错误数据提交给上层应用。如果这个错误发生在Metadata中，则会直接导致系统的Panic。
而且还有一种更为严重的情况是：在RAID 4和RAID
5阵列中，如果系统正在计算Parity数值，并再次写入新数据和新Parity值的时候发生断电，那么整个阵列的所有存储的数据都毫无意义了。
在ZFS中则提出了相对应的ZFS
Mirror和RAID-Z方式，它在负责读取数据的时候会自动和256位校验码进行校验，会主动发现这种Silent Data
Corruption，然后通过相应的Mirror硬
盘或者通过RAID-Z阵列中其他硬盘得到正确的数据返回给上层应用，并且同时自动修复原硬盘的Data Corruption 。
Fault Manager [9*a1z5+
在Solaris 10中，包含 一个ZFS诊断引擎和Solaris的 Fault Manager（这也是Solaris 10的
另一个新特性）交互，可以实时地诊断分析并且报告ZFS Pool和存储设备的错误，用户可以通过Fault
Manager及时得到一个非常友善的消息。这个诊断引擎虽然不会采取主动的行为去修复或者解决
问题，但是会在消息中提示系统管理员可采取的动作。类似下面一个ZFS报错消息，其中REC-ACTION就是建议采取的动作：
SUNW-MSG-ID: ZFS-8000-D3， TYPE: Fault， VER: 1， SEVERITY: Major
EVENT-TIME: Fri Mar 10 11:09:06 MST 2006
PLATFORM: SUNW，Ultra-60， CSN: -， HOSTNAME: neo
SOURCE: zfs-diagnosis， REV: 1.0
EVENT-ID: b55ee13b-cd74-4dff-8aff-ad575c372ef8
DESC: A ZFS device failed. Refer to http://sun.com/msg/ZFS-8000-D3
for more information.
AUTO-RESPONSE: No automated response will occur.
IMPACT: Fault tolerance of the pool maybe compromised.
REC-ACTION: Run ’zpool status -x’ and replace the bad device.
7. 安全
在安全上，ZFS支持类似NT风格NFSv4版的ACL（读取控制列表）。而且前面所提到的256位验证码，用户可选择多种验证方式，包括SHA-256验证算法，从而在物理存储单元级别上保证数据的安全性。
8. 超强功能
ZFS作为“最后一个文件系统”，涵盖了基本的文件系统和Volume管理的功能，同时
一并提供许多企业级别的超强功能：Quota(配额)，Reservation(预留)， Compression(压 缩)，
Snapshot(快照)，Clone（克隆）。并且速度非常快。有了这个文件系统，大家再也不需要任何Volume Manager了。
兼容性
ZFS是一个完全兼容POSIX规范的文件系统，所以处于上层的应用程序是完全不受影响。ZFS也提供一个Emulated
Volume模块，可以把任何一个ZFS文件系统作为普通的块设备使用。同时ZFS也可以使用基于Volume
Manager构建的Volume作为存储设备单 元。这样在不需要修改应用程序，不修改已有文件系统下，给了大家最大的自由度去获得ZFS提供的各
种特性。
10. 开源
ZFS是Sun Microsystems公 司作为OpenSolaris的一个开源项目运作并且完全免费使用，点击这里(http://www.opensolaris.org/os/community/zfs/source/
) 可以直接浏览到ZFS的代码。 这就代表着我们不仅同时可以享受商业公司的高质量，也可以获得开源模式的优点。
虽然目前只有Solaris支持该文件系统，但是这种开源的模式必定会促进更多基于ZFS的应用。现在已经有国外开发者正在将ZFS移植到Linux和
Mac OS上来。如果想要体验一下ZFS，由于目前它和Solaris 10绑定在一起，所以需要下载最新版的Solaris 10 6/06 (http://www.sun.com/software/solaris/get.jsp)。
Linux 与文件系统具有有趣的关系。因为 Linux
是开放式的，所以它往往是下一代文件系统和创新文件系统理念的关键开发平台。两个有趣的最新示例包括可大规模扩展的 Ceph 和连续快照文件系统
nilfs2（当然，主力文件系统，比如第四个扩展文件系统 [ext4] 的演化）。它还是旧有文件系统的考古遗址 — DOS
VFAT、Macintosh(HPFS)、VMS ODS-2 和 Plan-9 的远程文件系统协议。但是对于您发现在 Linux
内受支持的所有文件系统，有一个因其实现的功能会让人产生相当大的兴趣：Oracle 的 Zettabyte 文件系统（Zettabyte File
System，ZFS）。
ZFS 是由 Sun Microsystems（在 Jeff Bonwick 下）设计和开发的，在 2004 年首次公布，并在 2005
年融入 Sun
Solaris）。虽然将最流行的开放式操作系统与谈论最多的、功能最丰富的文件系统配对在一起是最理想的匹配，但是许可问题制约了集成。Linux
通过 GNU 公共许可证（General Public License，GPL）获得保护，而 ZFS 是由 Sun
的通用开发和发布许可（Common Development and Distribution
License，CDDL）涵盖的。这些许可协议具有不同的目标并引入了冲突的限制。所幸，这并不意味着您作为 Linux 用户不能享受 ZFS
及其提供的功能。
本文探究了在 Linux 中使用 ZFS 的两种方法。第一种使用了用户空间文件系统（Filesystem in
Userspace，FUSE）系统来推动 ZFS 文件系统到用户空间以便避免许可问题。第二种方法是一个 ZFS 本机端口，用于集成到 Linux
内核，同时避免知识产权问题。
将 ZFS 称为文件系统有点名不副实，因为它在传统意义上不仅仅是个文件系统。ZFS
将逻辑卷管理器的概念与功能丰富的和可大规模扩展的文件系统结合起来。让我们开始先探索一些 ZFS 所基于的原则。首先，ZFS
使用池存储模型，而不是传统的基于卷的模型。这意味着 ZFS
视存储为可根据需要动态分配（和缩减）的共享池。这优于传统模型，在传统模型中，文件系统位于卷上，使用独立卷管理器来管理这些资产。ZFS
内嵌入的是重要功能集（如快照、即写即拷克隆、连续完整性检查和通过 RAID-Z 的数据保护）的实现。更进一步，可以在 ZFS
卷的顶端使用您自己最喜爱的文件系统（如 ext4）。这意味着您可以获得那些 ZFS
的功能，如独立文件系统中的快照（该文件系统可能并不直接支持它们）。
但是 ZFS 不只是组成有用文件系统的功能集合。相反，它是构建出色文件系统的集成和补充功能的集合。让我们来看看其中的一些功能，然后再看看它们的一些实际应用。
正如前面所讨论的，ZFS 合并了卷管理功能来提取底层物理存储设备到文件系统。ZFS 对存储池（称为 zpools
）进行操作，而不是直接查看物理块设备，存储池构建自虚拟驱动器，可由驱动器或驱动器的一部分物理地进行表示。此外，可以动态构造这些池，甚至这些池正在活跃地使用时也可以。
ZFS
使用即写即拷模型来管理存储中的数据。虽然这意味着数据永远不会写入到位（从来没有被覆盖），而是写入新块并更新元数据来引用数据。即写即拷有利的原因有
多个（不仅仅是因为它可以启用的快照和克隆等一些功能）。由于从来不覆盖数据，这可以更简单地确保存储永远不会处于不一致的状态（因为在新的写入操作完成
以后较早的数据仍保留）。这允许 ZFS 基于事务，且更容易实现类似原子操作等的功能。
即写即拷设计的一个有趣的副作用是文件系统的所有写入都成为顺序写入（因为始终进行重新映射）。此行为避免存储中的热点并利用顺序写入的性能（比随机写入更快）。
可以使用 ZFS 的众多保护方案之一来保护由虚拟设备组成的存储池。您不但可以跨两个或多个设备（RAID
1）来对池进行镜像，通过奇偶校验来保护该池（类似于 RAID 5），而且还可以跨动态带区宽度（后面详细介绍）来镜像池。基于池中设备数量，ZFS
支持各种不同的的奇偶校验方案。例如，您可以通过 RAID-Z (RAID-Z 1) 来保护三个设备；对于四个设备，您可以使用 RAID-Z
2（双重奇偶校验，类似于 RAID6）。对于更大的保护来说，您可以将 RAID-Z 3 用于更大数量的磁盘进行三重奇偶校验。
为提高速度（不存在错误检测以外的数据保护），您可以跨设备进行条带化（RAID 0）。您还可以创建条带化镜像（来镜像条带化设备），类似于 RAID 10。
ZFS 的一个有趣属性随 RAID-Z、即写即拷事务和动态条带宽度的组合而来。在传统的 RAID 5 体系结构中，所有磁盘都必须在条带内具有其自己的数据，或者条带不一致。因为没有方法自动更新所有磁盘，所以这可能产生众所周知的 RAID 5 写入漏洞问题
（其
中在 RAID 集的驱动器中条带是不一致的）。假设 ZFS
处理事务且从不需要写入到位，则写入漏洞问题就消除了。此方法的另外一个便捷性体现在磁盘出现故障且需要重建时。传统的 RAID 5
系统使用来自该集中其他磁盘的数据来重建新驱动器的数据。RAID-Z
遍历可用的元数据以便只读取有关几何学的数据并避免读取磁盘上未使用的空间。随着磁盘变得更大以及重建次数的增加，此行为变得更加重要。
虽然数据保护提供了在故障时重新生成数据的能力，但是这并不涉及处于第一位的数据的有效性。ZFS 通过为写入的每个块的元数据生成 32
位校验和（或 256 位散列）解决了此问题。在读取块时，将验证此校验和以避免静默数据损坏问题。在有数据保护（镜像或
AID-Z）的卷中，可自动读取或重新生成备用数据。
在 ZFS 上校验和与元数据存储在一起，所以可以检测并更正错位写入 — 如果提供数据保护（RAID-Z）—。
由于 ZFS 的即写即拷性质，类似快照和克隆的功能变得易于提供。因为 ZFS 从不覆盖数据而是写入到新的位置，所以可以保护较早的数据（但是在不重要的情况下被标记为删除以逆转磁盘空间）。快照
就是旧块的保存以便及时维护给定实例中的文件系统状态。这种方法也是空间有效的，因为无需复制（除非重新写入文件系统中的所有数据）。克隆
是一种快照形式，在其中获取可写入的快照。在这种情况下，由每一个克隆共享初始的未写入块，且被写入的块仅可用于特定文件系统克隆。
传统的文件系统由匹配后端存储（512 字节）的静态大小的块组成。ZFS 为各种不同的使用实现了可变块大小（通常大小达到
128KB，但是您可以变更此值）。可变块大小的一个重要使用是压缩（因为压缩时的结果块大小理想情况下将小于初始大小）。除了提供更好的存储网络利用
外，此功能也使存储系统中的浪费最小化（因为传输更好的数据到存储需要更少的时间）。
在压缩以外，支持可变块大小还意味着您可以针对所期望的特定工作量优化块大小，以便改进性能。
ZFS 并入了许多其他功能，如重复数据删除（最小化数据重复）、可配置的复制、加密、缓存管理的自适应更换缓存以及在线磁盘清理（标识并修复在不使用保护时可以修复的潜在错误）。它通过巨大的可扩展性来实现该功能，支持 16 千兆兆个字节的可寻址存储（264
字节）。
现在您已经了解了 ZFS 背后的一些抽象概念，让我们在实践中看看其中的一些概念。本演示使用了 ZFS-FUSE。FUSE
是一种机制，允许您在没有内核代码（除 FUSE
内核模块和现有的文件系统代码以外）情况下在用户空间中实现文件系统。该模块为用户和文件系统实现提供从内核文件系统接口到用户空间的桥梁。首先，安装
ZFS-FUSE 包（下面的演示针对 Ubuntu）。
安装 ZFS-FUSE 很简单，尤其是在使用 apt
的 Ubuntu 上。下面的命令行安装了您开始使用 ZFS-FUSE 所需的一切：
$ sudo apt-get install zfs-fuse |
此命令行安装 ZFS-FUSE 和所有其他依赖包（ 我的也需要 libaiol
），为新的程序包执行必要的设置并启动 zfs-fuse
守护进程。
在此演示中，您使用环回设备以便在主机操作系统内将磁盘仿真为文件。要开始此操作，请通过 dd
实用程序（参见清单 1）创建这些文件（使用 /dev/zero 作为源）。在创建了四个磁盘映像之后，使用 losetup
将磁盘映像与环路设备关联在一起。
$ mkdir zfstest $ cd zfstest $ dd if=/dev/zero of=disk1.img bs=64M count=1 1+0 records in 1+0 records out 67108864 bytes (67 MB) copied, 1.235 s, 54.3 MB/s $ dd if=/dev/zero of=disk2.img bs=64M count=1 1+0 records in 1+0 records out 67108864 bytes (67 MB) copied, 0.531909 s, 126 MB/s $ dd if=/dev/zero of=disk3.img bs=64M count=1 1+0 records in 1+0 records out 67108864 bytes (67 MB) copied, 0.680588 s, 98.6 MB/s $ dd if=/dev/zero of=disk4.img bs=64M count=1 1+0 records in 1+0 records out 67108864 bytes (67 MB) copied, 0.429055 s, 156 MB/s $ ls disk1.img disk2.img disk3.img disk4.img $ sudo losetup /dev/loop0 ./disk1.img $ sudo losetup /dev/loop1 ./disk2.img $ sudo losetup /dev/loop2 ./disk3.img $ sudo losetup /dev/loop3 ./disk4.img $ |
有了四台设备作为您的 ZFS 块设备（总大小 256MB），使用 zpool
命令来创建您的池。您可以使用 zpool
命令来管理 ZFS 存储池，不过您将看到，您可以将其用于各种其他目的。下面的命令要求通过四个设备创建 ZFS 存储池并通过 RAID-Z 提供数据保护。在此命令后为一个列表请求，以便提供您池中的数据（参见清单 2）。
$ sudo zpool create myzpool raidz /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3 $ sudo zfs list NAME USED AVAIL REFER MOUNTPOINT myzpool 96.5K 146M 31.4K /myzpool $ |
您还可以研究池的一些属性，如清单 3 所示，其代表默认值。对于其他事项，您可以查看可用容量和已使用的部分。（为了简洁，此代码已经被压缩。）
$ sudo zfs get all myzpool NAME PROPERTY VALUE SOURCE myzpool type filesystem - myzpool creation Sat Nov 13 22:43 2010 - myzpool used 96.5K - myzpool available 146M - myzpool referenced 31.4K - myzpool compressratio 1.00x - myzpool mounted yes - myzpool quota none default myzpool reservation none default myzpool recordsize 128K default myzpool mountpoint /myzpool default myzpool sharenfs off default myzpool checksum on default myzpool compression off default myzpool atime on default myzpool copies 1 default myzpool version 4 - ... myzpool primarycache all default myzpool secondarycache all default myzpool usedbysnapshots 0 - myzpool usedbydataset 31.4K - myzpool usedbychildren 65.1K - myzpool usedbyrefreservation 0 - $ |
现在，让我们实际使用 ZFS 池。首先，在您的池中创建目录，然后在该目录中启用压缩（使用 zfs set
命令）。其次，将文件复制到其中。我已经选择了大小 120KB 左右的文件来查看 ZFS 压缩的效果。请注意您的池挂载在根目录上，因此就像您的根文件系统内的目录一样加以处理。一旦复制该文件，您就可以列出它来表示文件已存在（但与原来同样大小）。通过使用 dh
命令，您可以看到文件大小为原来的一半，这说明 ZFS 已经将其压缩。您还可以查看 compressratio
属性，了解您的池有多少已经被压缩（使用默认压缩程序，gzip）。清单 4 显示了该压缩。
$ sudo zfs create myzpool/myzdev $ sudo zfs list NAME USED AVAIL REFER MOUNTPOINT myzpool 139K 146M 31.4K /myzpool myzpool/myzdev 31.4K 146M 31.4K /myzpool/myzdev $ sudo zfs set compression=on myzpool/myzdev $ ls /myzpool/myzdev/ $ sudo cp ../linux-2.6.34/Documentation/devices.txt /myzpool/myzdev/ $ ls -la ../linux-2.6.34/Documentation/devices.txt -rw-r--r-- 1 mtj mtj 118144 2010-05-16 14:17 ../linux-2.6.34/Documentation/devices.txt $ ls -la /myzpool/myzdev/ total 5 drwxr-xr-x 2 root root 3 2010-11-20 22:59 . drwxr-xr-x 3 root root 3 2010-11-20 22:55 .. -rw-r--r-- 1 root root 118144 2010-11-20 22:59 devices.txt $ du -ah /myzpool/myzdev/ 60K /myzpool/myzdev/devices.txt 62K /myzpool/myzdev/ $ sudo zfs get compressratio myzpool NAME PROPERTY VALUE SOURCE myzpool compressratio 1.55x - $ |
最后，让我们看看 ZFS 的自修复功能。请回想在您创建池时，您要求四个设备具有 RAID-Z。通过使用 zpool status
命令您可以检查池的状态, 如清单 5 所示。如清单所示，您可以看到池的元素（RAID-Z 1 以及四个设备）。
$ sudo zpool status myzpool pool: myzpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM myzpool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 loop0 ONLINE 0 0 0 loop1 ONLINE 0 0 0 loop2 ONLINE 0 0 0 loop3 ONLINE 0 0 0 errors: No known data errors $ |
现在，让我们强制执行一个错误到池中。对于此演示来说，转到后台并损坏组成设备的磁盘文件（disk4.img，通过 loop3
设备显示在 ZFS 中）。使用 dd
命令将整个设备清零（参见清单 6）。
$ dd if=/dev/zero of=disk4.img bs=64M count=1 1+0 records in 1+0 records out 67108864 bytes (67 MB) copied, 1.84791 s, 36.3 MB/s $ |
ZFS 目前未意识到损坏，但是您可以通过请求池的清理，强制池发现问题。如清单 7 所示，ZFS 现在认识到（loop3
设备的）损坏并建议操作以便替换该设备。还请注意在 ZFS 通过 RAID-Z 自我更正时，池仍然在线，您仍然可以访问您的数据。
$ sudo zpool scrub myzpool $ sudo zpool status myzpool pool: myzpool state: ONLINE status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-4J scrub: scrub completed after 0h0m with 0 errors on Sat Nov 20 23:15:03 2010 config: NAME STATE READ WRITE CKSUM myzpool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 loop0 ONLINE 0 0 0 loop1 ONLINE 0 0 0 loop2 ONLINE 0 0 0 loop3 UNAVAIL 0 0 0 corrupted data errors: No known data errors $ wc -l /myzpool/myzdev/devices.txt 3340 /myzpool/myzdev/devices.txt $ |
根据建议，引入新的设备到您的 RAID-Z 集以便充当新的容器。首先创建新的磁盘映像并通过 losetup
将其表示为设备。请注意此过程类似于将新的物理磁盘添加到集。然后，您使用 zpool replace
用新的设备（loop4
）交换已损坏的设备（loop3
）。检查池状态，您可以看到新设备具有一条消息，指示其上重新构建了数据（称为 resilvering
）以及移到那里的数据量。还请注意池仍保持在线，没有错误（对用户可见）。最后，再次清理池；在检查其状态以后，您将看不到存在问题，如清单 8 所示。
$ dd if=/dev/zero of=disk5.img bs=64M count=1 1+0 records in 1+0 records out 67108864 bytes (67 MB) copied, 0.925143 s, 72.5 MB/s $ sudo losetup /dev/loop4 ./disk5.img $ sudo zpool replace myzpool loop3 loop4 $ sudo zpool status myzpool pool: myzpool state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Sat Nov 20 23:23:12 2010 config: NAME STATE READ WRITE CKSUM myzpool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 loop0 ONLINE 0 0 0 loop1 ONLINE 0 0 0 loop2 ONLINE 0 0 0 loop4 ONLINE 0 0 0 59.5K resilvered errors: No known data errors $ sudo zpool scrub myzpool $ sudo zpool status myzpool pool: myzpool state: ONLINE scrub: scrub completed after 0h0m with 0 errors on Sat Nov 20 23:23:23 2010 config: NAME STATE READ WRITE CKSUM myzpool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 loop0 ONLINE 0 0 0 loop1 ONLINE 0 0 0 loop2 ONLINE 0 0 0 loop4 ONLINE 0 0 0 errors: No known data errors $ |
此简短演示探究了通过文件系统进行的卷管理的整合，并展示了管理 ZFS（即使是故障时）有多简单。
FUSE 中 ZFS 的优点是易于开始使用 ZFS，但是它的缺点是效率低。这种效率上的缺点是每个 I/O 都要求多个用户内核转换的结果。但是考虑到 ZFS 的流行，有另外一种提供更好性能的选项。
针对 Linux 内核的 ZFS 本地端口正在 Lawrence Livermore
国家实验室中处于顺利开发当中。虽然此端口仍然缺乏一些元素，如 ZFS 便携式操作系统接口（适用于 UNIX®）
层，但是这正在开发中。其端口提供大量有用的功能，尤其是当您有兴趣与 Lustre 一起使用 ZFS 时。（要了解更多细节，参阅 参考资料
。）
希望本文已经引起您进一步挖掘 ZFS 的欲望。从早前的演示中，您可以容易地设置 ZFS 并在大多数 Linux 发行版中运行 — 甚至是在拥有一些限制的内核中。虽然快照和克隆等主题并未在此处演示，但是 参考资料
部分提供了有关此主题的有趣的文章的链接。最后，Linux 和 ZFS 是最先进的技术，很难将它们分开。
【IT168 专稿】
原生支持Linux 的ZFS将很快发布，它是由劳伦斯利弗莫尔国家实验室(Lawrence Livermore National Laboratory)研制的将Sun 的 ZFS 文件系统以 CDDL 许可内核模块的方式移植到 Linux 上的项目。
不过就在发表该文章时，已经有可用的 FUSE(用户空间的文件系统)的 ZFS 模块了，而且由于它并非属于 Linux 内核的 GPL
范畴，所以可以合法地使用，不过它并没有带来什么性能上的提升。但在上周末在相关论坛和其他地方上出现了一些关于 ZFS-FUSE 的可靠性以及使用
FUSE 对于在实际硬件中使用会造成什么程度的影响的讨论。
测试说明及测试环境
最近国外有网站测试了 ZFS-FUSE——最近的稳定版和 Git 最新版——并将这个 ZFS Linux 移植的可选方案与原生的 EXT4 和 Btrfs 作了对比。我们将测试结果编译过来，以飨国内读者。
对于那些并不熟悉 GPL 许可的 Linux FUSE 模块的读者，应该了解它是从 Linux 2.6.14 版本开始出现在内核主分支中的
Linux 内核模块，它允许没有权限的用户通过 FUSE 模块在用户空间中创建他们自己的文件系统，接着提供与 Linux 内核交互的桥梁。
FUSE 也可以用于 BSD、OpenSolaris 和 Mac OS X 操作系统中。当使用用户空间中的 FUSE
文件系统时，它们并不需要遵守 GNU GPL，因为只有 FUSE 模块被加载到 Linux
内核上面，不过这样的连接方式会造成额外的效率损失。除了 ZFS-FUSE，还有几十种其他的 FUSE 文件系统，包括
ClamFS、httpFS、ChunkFS、vmware-mount，以及 GnomeVFS2 FUSE。
最新版本的
ZFS-FUSE 是 0.6.9 版，基于 Zpool 23 版本(比目前 LLNL/KQ Infotech 使用的 Zpool 18
好得多，带有过去 18 个版本的补丁并添加了类似重复数据删除(de-duplication)支持这样的功能)，并支持 NFS
共享、PowerPC 架构、多线程 ioctl 管理，以及其他的改进。ZFS 0.7.0 是目前还在开发中的版本，预计在 10
月初发布。在我们的 ZFS-FUSE 测试中，测试使用最新的稳定版 0.6.9 版和 0.7.0 Git 最新版，后者为 2010-08-28 的
Git 软件库中的最新官方代码。
KQ Infotech 是一家根据劳伦斯利弗莫尔国家实验的代码开发原生 ZFS 模块支持的公司，它称 FUSE
为“垃圾”。还有人认为“效率太差”或者“它与健全的原生内核支持相差十万八千里”。也有许多使用 FUSE
的支持者表示：“而且，他们发表一些堂皇的言论，否认基于 fuse 的文件系统的可行性，说实话，这些都是一派胡言。没错，zfs-fuse
文件系统可能会比较慢……但只是在旧版本的内核上。
这些问题造成的局限性已经被解决了。zfs-fuse
在正确配置下性能几乎和原生支持一样好!而且通过 fuse
的方式解决了主要的版权问题。这是双赢的!所以你就能容忍论坛上这边出来了一个人，胡言乱语一通，却没有提供任何实证，却希望所有人都和他一样疯疯癫癫?
他们想做的仅仅是炒作……给那些注定失败的东西炒作。炒作成大新闻。”这些针对 ZFS-FUSE 的热火朝天的两极化观点使得测试团队在测试原生
ZFS Linux 支持之前先测试一下它。
进行ZFS-FUSE 测试的硬件配置包括一块超频到 3.60GHz
的英特尔(Intel)Core i7 920 CPU、一块 ASRock X58 SuperComputer 主板、3GB 的 DDR3
系统内存、一快 60GB 的 OCZ Vertex 2 SSD 硬盘，以及一块 ATI Radeon HD 4670 显卡。
为
了这次 ZFS-FUSE测试，测试团队安装了原版的 Ubuntu 10.04.1 LTS(x86_64)并安装了最新的 2010-08-26 的
Linux 2.6.36 的 Git 代码。并将 Phoronix 测试套件安装并运行于 OCZ Vertex 2 SSD
硬盘的第二个分区中，分别以 EXT4、Btrfs、ZFS-FUSE 0.6.9，以及 ZFS-FUSE 0.7.0(Git
2010-08-26)测试。接着，测试团队安装了 OpenSolaris b134 来测试它在 OCZ 固态硬盘上的原生 ZFS
支持。所有测试由 Phoronix 测试套件进行。
测试数据及结论分析
首先是 Apache
服务器测试，和 EXT4 和 Btrfs 相比使用 ZFS-FUSE 的结果有很大的性能降低。在 Ubuntu Linux 上使用
ZFS-FUSE 在每秒内能够处理的请求数量比用 Ubuntu Lucid Lynx 默认的文件系统 EXT4 低了 42%。
在 PostgreSQL 工作负荷测试中 EXT4 的性能比在 Linux 用户空间中测试的 ZFS 文件系统快了 5 倍有余。最新的
ZFS-FUSE 0.7 版本的 ZFS-FUSE Git 代码比 ZFS-FUSE 0.6.9 性能提高了 6%，但不明显，这无法与填补与
EXT4 性能之间的差距。有趣的是，ZFS-FUSE 的性能实际上比 Btrfs 要好，不过据称目前在 Btrfs 上的 PostgreSQL
服务器性能是众所周知的糟糕。我们成功地在 OpenSolaris b134 的 ZFS 中运行了测试项目，它比 Linux 上的
ZFS-FUSE Git 代码快了 61%。
PostgreSQL 磁盘性能测试中 EXT4 比 ZFS-FUSE 快了 6 倍多，不过在 PostMark
电子邮件服务器性能测试中则高出了 8 倍。在 OpenSolaris 上的 ZFS 性能比 ZFS-FUSE 0.6.9
快了一倍，实际上正好比它的两倍少那么一点。虽然 ZFS 是为 OpenSolaris 设计的，但它也只能够达到 Btrfs 31% 的速度，仅有
EXT4 22% 的速度。
Btrfs 在 SQLite 测试(与 PostgreSQL PGbench 类似)中只得了个安慰奖，不过广泛流行的 EXT4 文件系统还是几乎比 Linux 上的 ZFS-FUSE 快了一倍。
EXT4、Btrfs 和 OpenSolaris 上的 ZFS 都运行得不错，比分接近，然而 ZFS-FUSE——0.6.9 稳定版和 0.7.0 开发最新版——都被甩在了后面。
Btrfs 在这一测试中比 ZFS-FUSE 快了 2 倍，而 EXT4 则甩开了它们 3 又三分之一倍。在 OpenSolaris 上的原生 ZFS 的性能和 Linux 2.6.36 内核上的 Btrfs 势均力敌。
ZFS 阵营，无论是 ZFS-FUSE 还是 OpenSolaris 上的 ZFS，在遇到多线程随机写入测试时都完败。Btrfs 的速度是 ZFS-FUSE 的 24.47 倍，后者在随机写入时只能达到 5MB/s 的速度。
当测试以 64Kb 大小的块的 IOzone 写入 8GB 数据时，EXT4 和 Btrfs(译者注：此处疑为笔误)的速度为 ZFS-FUSE 的 1.64～1.67 倍。
最后一项测试，使用 IOzone 读取 8GB 数据中，ZFS-FUSE 的磁盘读取性能结果实际上和 EXT4 和 Btrfs 相近，不过那是因为 ZFS 模块在读取时使用了缓存的缘故。
鉴于一些 Phoronix Premium成员要求在文件系统测试中同时提供 CPU 占用的结果，本文接下来就提供这些信息。
如上图所示，英特尔 Core i7 的 CPU 使用量在使用 Linux 的 ZFS-FUSE 或运行 OpenSolaris 使用原生 ZFS 支持时都较低。
虽然在 PostMark 测试中使用 ZFS-FUSE 的 CPU 负荷较低，差距也仅仅是百分之几而已。在运行 Apache 时，ZFS-FUSE 的 CPU 负载大幅提高，比原生的 Linux 文件系统高了许多，几乎是其 3 倍多。
在使用 Linux 的 ZFS-FUSE 时一定会引起性能损失，要看你是否利用到甲骨文(Oracle)/Sun 的 ZFS
文件系统中的其他特性才能决定这点性能差距是否值得。即使是在最新的 Linux 2.6.36 内核上的最新的稳定版和不稳定版
ZFS-FUSE，在使用用户空间的 ZFS 时都会有明显的性能损失。
不过我们对劳伦斯利弗莫尔国家实验室或者 KQ Infotech 带来的原生 ZFS Linux 模块与 ZFS-FUSE
相比性能如何很感兴趣。就算是 OpenSolaris 上原生的 ZFS 模块都无法与 Linux 和 EXT4/Btrfs
的组合比肩，所有我们将要看到的原生 ZFS Linux 的结果一定很有意思。也有人会争辩说那些兼容 OpenSolaris 的测试项目的结果是被
Solaris Nevada 内核的其他部分产生的瓶颈所影响了，但即使是在 FreeBSD 上的 ZFS 也比 EXT4 和 Btrfs
文件系统要慢。原生ZFS 的测试代码约在十月慕尼黑啤酒节之前发布。