ZFS 崇拜

IT 圈子里发展出某种近乎崇拜或“粉丝”心态是相当常见的。是什么引发了人们对技术和产品的这种反应，我并不太确定，但它确实会发生，这一点无可否认。有一个领域我从没想过会看到这种现象出现，那就是文件系统领域——它是最“底层”的系统组件之一，而且直到不久前，即便在相当技术化的圈子里也几乎不受任何关注。我们得承认，分不清某项功能来自 Active Directory 还是来自 NTFS 几乎是普遍现象。文件系统，说白了，就是被忽视的。自从 Windows NT 4 发布、NTFS 成为唯一可行的选项以来，“文件系统并非操作系统不可分割的组件、文件存储或许还有其他选择”这一观念已经几乎彻底消退。直到不久前才有所改变。

在某种小程度上唯一没有发生这种情况的社区是 Linux 社区，但即便在那里，Ext2 及其后代也如此彻底地赢得了人心，以至于尽管其他文件系统广泛可用，替代性文件系统却被边缘化，历史上只有 XFS 受到过一些关注，而即便是它所受到的关注也非常少。

较近时期出现某种真正奇特行为的，是围绕 Oracle 的 ZFS 文件系统——它最初是为 Solaris 操作系统和 X4500 “Thumper” 开放存储平台开发的（最初是在 Oracle 收购之前于 Sun 的主持下）。在 ZFS 发布之时（九年前），相互竞争的文件系统大多没有准备好应对人们预期在未来数年中会构建出来的大型磁盘阵列。ZFS 被设计用来应对它们，并开启了大规模文件系统的时代。与当时大多数文件系统一样，ZFS 仅限于单一操作系统，因此，尽管它被广泛视为文件系统设计上的一次巨大飞跃，它在存储领域却激起了很少的涟漪，而在“系统”领域激起的涟漪更少——在那里，相当长一段时间里，即便是 Solaris 管理员通常也只把它视为一个值得关注的兴趣点，大多选择坚持使用他们多年来一直在用的、久经考验且可靠的 UFS。

ZFS 确实是一个开创性的文件系统，我曾是、并且至今仍是它的一位坚定拥护者。但极其重要的是要理解 ZFS 为何要做它所做之事、它的目标是什么、那些目标为何重要，以及它如何适用于今天的我们。ZFS 的复杂性导致了关于这个文件系统如何工作、以及何时适合使用它的大量混淆和误解。

ZFS 的首要目标是打造一个能够很好地扩展到超大磁盘阵列的文件系统。在它问世之时，ZFS 所能达到的规模在其他文件系统中闻所未闻，但现实世界中并不真正需要一个文件系统能够增长到那么大。等到需求出现之时，许多其他文件系统，如 NTFS、XFS、Ext3 等，都已经扩展以满足该需求。ZFS 无疑引领了走向更大文件系统处理能力的潮流，但不久之后便有许多其他文件系统加入进来。

由于 ZFS 起源于 Solaris 世界，而在那里，与所有大型 UNIX 系统一样，没有硬件 RAID，因此必须使用软件 RAID。Solaris 一直都有作为其自身子系统提供的软件 RAID。当时做出的决定是，将一套全新的软件 RAID 实现直接构建进 ZFS。这将允许通过单一的工具集来简化 RAID 层和文件系统二者的管理。如同常被认为的那样，它并没有为 ZFS 引入任何重大的改变或优势，而只是把软件 RAID 层的接口从一套自己的命令集转移为 ZFS 命令集的一部分。

ZFS 的 RAID 实现在奇偶校验 RAID 级别中引入了可变宽度条带。这一创新堵上了一个被称为“写洞”的次要奇偶校验 RAID 风险。这一创新非常不错，但来得很晚，因为可靠奇偶校验 RAID 的时代正开始走向终结，而写洞问题当时已经被视为奇偶校验阵列中一种无人提及的“背景噪声”风险，因为它通常不被视为一种威胁——这是由于它已经通过使用电池备份的阵列缓存、以及大约在同一时期出现的非易失性阵列缓存而被消除：避免断电，你就避免了写洞。ZFS 需要解决这个问题，因为作为软件 RAID，它面临写洞的风险比硬件 RAID 更大，原因是它没有机会拥有一个能防范断电的缓存——硬件 RAID 为阵列提供了额外一层电源保护的可能性。

ZFS 无意中所做出的真正“创新”在于，它没有只是去实现 1、5、6 和 10 这些常规的 RAID 级别，而是用它们自己的命名约定为这些级别“打上了品牌”。RAID 5 被称为 RAIDZ。RAID 6 被称为 RAIDZ2。RAID 1 干脆被称为镜像。以此类推。这在当时被广泛认为是愚蠢的、徒增混淆的，但结果证明，正是那种混淆，成了多年以后 ZFS 复兴的基石。

需要指出的是，ZFS 后来添加了业界首个 RAID 7（亦称 RAID 7.3）三重奇偶校验 RAID 系统的生产级实现，并将其打上 RAIDZ3 的品牌。这一较晚的添加对于那些需要极致容量、同时又要保持极其安全、但愿意为此牺牲性能的大规模阵列而言，是一项重要的创新。这至今仍是 ZFS 独有的一项特性，但却是一项很少被使用的特性。

本着坍缩存储栈、并使用单一命令集来管理存储各个方面的精神，逻辑卷管理功能也被纳入了 ZFS。在某些圈子里，人们常错误地认为 ZFS 引入了逻辑卷管理，但几乎所有企业平台——包括 AIX、Linux、Windows，乃至 Solaris 自身——多年前就已经拥有了逻辑卷管理。ZFS 这样做并不是为了引入一种新范式，而只是为了整合管理，并将三个关键存储层（RAID、逻辑卷管理和文件系统）全部封装进单一实体，使其更易于管理，并能在栈中上下提供固有的通信。这种方法有利有弊，将近十年之后，业界仍未形成定论。

将三个系统整合为一所带来的最重要的方面之一，是我们现在有了一个非常令人困惑的产品需要讨论。ZFS 是一个文件系统，没错，但它不仅仅是一个文件系统。它是一个逻辑卷管理器，但不仅仅是一个逻辑卷管理器。人们把 ZFS 称为文件系统，这是它的主要功能，但它远不止是一个文件系统，这一点会非常令人困惑，并使得与其他存储系统进行比较变得困难。我相信，当时并未预见到这种混淆。

这种令人困惑的合并所导致的结果是，ZFS 常常被拿来与其他文件系统（如 XFS 或 Ext4）进行比较。但这令人困惑，因为 ZFS 是一个完整的栈，而 XFS 只是栈的一个方面。把 ZFS 与 MD（Linux 软件 RAID）/ LVM / XFS，或与 SmartArray（HP 硬件 RAID）/ LVM / XFS 相比较，会比单独与 XFS 相比要恰当得多。否则看上去就好像 ZFS 充满了 XFS 所缺乏的功能，但实际上这只是语义上的胜利。ZFS 拥护者们经常吹捧的大多数功能并非源自 ZFS，并且早在 ZFS 存在之前就已经在那些替代性文件系统中普遍可用了。但很难去比较“你的文件系统能做到那个吗”，因为答案是“不能……是我的 RAID 或我的逻辑卷管理器做到那个的。”而且确实，提供 RAIDZ 的并不是作为文件系统的 ZFS，而是作为软件 RAID 子系统的 ZFS 在这样做。

为了优雅地处理超大文件系统，数据完整性特性被构建进了 ZFS，其中包括贯穿整个文件系统的校验和或哈希校验，它能够利用内含的软件 RAID 来修复损坏的文件。鉴于未来 ZFS 文件系统的预期规模，这被视为是必要的。文件系统损坏是一种很少见到的现象，但随着文件系统规模的增长，风险也随之增加。ZFS 这项鲜为人知的特性，可能是它最了不起的一项。

ZFS 还改变了文件系统检查的处理方式。由于假定 ZFS 将被用于超大文件系统，人们真切地担心启动时的文件系统检查可能需要长得不可思议的时间才能完成，因此找到了一种替代策略。系统不再等到重启时去做检查，而是要求运行一个“擦洗”（scrubbing）过程，在系统运行期间执行类似的检查。这在系统处于活动状态时需要更多的系统开销，但系统能够从意外重启中更快地恢复。这是一种权衡，但却是被广泛视为非常正面的权衡。

ZFS 在其逻辑卷层中拥有强大的快照能力，并在其 RAID 层中实现了非常稳健的缓存机制，使 ZFS 成为许多用例的极佳选择。这些特性在 ZFS 中并非独有，而是在比 ZFS 更古老的系统中广泛可用。然而，它们各自都是非常出色的实现，并且由于 ZFS 的本质而集成得非常好。

ZFS 曾经一度是开源的，在那个时代，它的代码成为了 Apple 的 Mac OSX 和 FreeBSD 操作系统的一部分，因为它们与 ZFS 的许可证兼容。Linux 当时由于围绕许可的种种困难而没有获得 ZFS。倘若 ZFS 的许可允许 Linux 不受束缚地使用它，今天的 Linux 格局很可能会大为不同。Mac OSX 最终放弃了 ZFS，因为在那种环境下它被认为没有足够的优势来证明其存在的合理性。FreeBSD 紧紧抓住了 ZFS，随着时间推移，它成为了该平台上最受欢迎的文件系统，尽管 UFS 同样仍被大量使用。Oracle 在收购 Sun 之后关闭了 ZFS 的源代码，使 FreeBSD 的 ZFS 版本得不到持续更新，而 Oracle 则继续在内部为 Solaris 开发 ZFS。

如今 Solaris 仍在使用最初的 ZFS 实现，自其与开源社区分道扬镳以来已有若干更新。FreeBSD 及其他系统则继续使用代码闭源时所处状态下的 ZFS，不再能够获取 Oracle 的最新更新。最终，更新这套被遗弃的开源 ZFS 代码库的工作被接手，如今被称为 OpenZFS。OpenZFS 仍处于起步阶段，尚未真正留下印记，但在开源领域有一定潜力去重振 ZFS 平台——不过在此时，OpenZFS 仍落后于 ZFS。

过去几年里，这一领域的开源开发更多地聚焦于 ZFS 的新对手 BtrFS，它在 Linux 上原生开发，并得到许多主要操作系统厂商的良好支持。BtrFS 非常新生，但正大步迈进，以在已实现的功能上达到与 ZFS 的特性对等，同时它怀有宏大的抱负，并且由于 ZFS 的闭源本质而拥有市场势头的优势。BtrFS 与 ZFS 一样，也是由 Oracle 发起的，并被广泛视为 Oracle 对未来的看法——即便在 Oracle 内部，它也是 ZFS 的替代者。在此时，BtrFS 已经像 ZFS 一样合并了文件系统、逻辑卷管理和软件 RAID 层，实现了用于文件系统完整性的校验和，扩展规模甚至比 ZFS 还大（绝对上限相同，但能处理更多文件），具备写时复制快照等等。

毫无疑问，ZFS 在它的鼎盛时期是一个了不起的文件系统，时至今日仍是一个领先者。我在 2005 年是它的拥护者，至今仍对它深信不疑。但令我感到悲哀的是，看到 ZFS 周围的社区染上了一种对它毫无益处的狂热和盲信，以至于提及 ZFS 几乎都显得像是一种负面——ZFS 如此普遍地因错误的理由而被选用：主要是相信它的特性别处都不存在、相信它的 RAID 不受那些 RAID 级别始终会受制的风险和限制、或相信它是为了一个与它实际设计目的不同的目的（主要是性能）而设计的。而当 ZFS 确实是一个好选择时，它又常常基于不真实的假设而被拙劣地实现。

当然，ZFS 本身并无过错。据我所知，它的企业支持者或它的开源开发者也没有过错。ZFS 似乎出岔子的地方，在于一个松散、非官方的社区——它直到最近才开始认识 ZFS，常常以为它是新的或“下一代”的，仅仅因为他们自己直到最近才发现它。据我所见，这几乎从来不是通过 Solaris 或 FreeBSD 的渠道，而几乎完全是那些希望使用像 FreeNAS 或 NAS4Free 这样打包好的“NAS 操作系统”、却又不熟悉 UNIX 操作系统的小型企业。这些打包好的 NAS 操作系统主要由那些既不具备深厚 UNIX 技能、也不具备存储技能的 IT 部门使用，因而他们对 Windows 之外更广阔的文件系统世界接触甚少，对逻辑卷管理和 RAID（尤其是软件 RAID）往往接触很少乃至完全没有，这似乎催生了一种围绕 ZFS 的“神话”文化，使其呈现出一种近乎不容置疑、绝无谬误的地位。

这种近乎崇拜的追随以及对 ZFS 的普遍误解，往往导致对 ZFS 的误用，或者导致一连串基于错误假设的决策，从而可能使人误入歧途。

这一领域最令人惊讶的变化之一，是追随的对象从硬件 RAID 转向了软件 RAID。传统上，软件 RAID 在 Windows 管理圈子里是一个不受待见者，且并无充分理由——Windows 管理员和小型企业往往不熟悉更大型的 UNIX 服务器，他们相信硬件 RAID 无处不在，而实际上，更大规模的系统一向使用软件 RAID。硬件 RAID 几乎在整个业界都被视为一种必需品，而软件 RAID 则被彻底排斥。如今面对“ZFS 崇拜”运动的同一批受众，现在却以恰恰相反的方式做出反应，相信硬件 RAID 是糟糕的、而 ZFS 的软件 RAID 是唯一可行的选项。这种转变是剧烈的，而两种态度都不成立——硬件 RAID 和软件 RAID 二者、以及它们在许多实现中，都是非常有效的选项，甚至在使用 ZFS 时，使用硬件 RAID 也很可能轻易就是合适的。

ZFS 常常被选用，是因为人们相信它是文件系统中性能最高的选项，但这从来都不是 ZFS 的一个关键设计目标。使它能够扩展得如此之大、并处理存储如此众多不同方面的那些特性，实际上使得做到高性能变得非常困难。在 ZFS 诞生之时，它甚至都没有被预期会像与它运行在同一系统上的那个久负盛名的 UFS 那样快。然而，这一点往往是次要的，因为文件系统的性能在很大程度上是无关紧要的——所有现代文件系统都极其快速，而文件系统的速度很少会是一个重要因素，尤其是在那些规模极其庞大的高端存储系统之外。

Phoronix 于 2013 年针对 Linux 上十种文件系统所做的一项有趣研究表明，不同文件系统因工作负载而异，存在巨大的差异，但就整体性能而言并无明显的赢家。该研究确凿地表明，将工作负载与文件系统相匹配才是最重要的选择，ZFS 即便在其较现代的实现中也落在所有主流文件系统中较慢的一侧，而且在不深入理解工作负载的情况下出于性能原因去选择文件系统将导致不可预测的性能——如果性能是一个重要因素，就不应盲目地选择任何文件系统。遗憾的是，由于该测试是在 Linux 上完成的，它缺少了 UFS——后者往往是 ZFS 的关键竞争对手，尤其是在 Solaris 和 FreeBSD 上——并且缺少了来自 Mac OSX 的 HFS+。

从硬件 RAID 转向软件 RAID，对那些没有 UNIX 经验的部门而言，还带来了额外的、往往未被预见的风险。虽然 ZFS 允许热插拔，但人们常常忘记热插拔主要是硬件的一项特性，而非软件的；而且人们也普遍不知道，盲插（在操作系统中未先将硬盘下线就将其移除）并不等同于热插拔，对于那些从硬件 RAID 传统转过来的部门而言，这可能导致灾难——硬件 RAID 曾为他们透明地处理了兼容性、热插拔和盲插，而软件 RAID 系统则需要多得多的规划、协调以及对系统的理解才能安全使用。

关于 ZFS 一个较次要、但仍然常见的误解，是认为它是一个适用于共享 DAS 或 SAN 场景的集群文件系统，诸如 OCFS、VxFS 和 GFS2。ZFS 并不是一个集群文件系统，并且在这一领域与它所有常见的竞争对手有着相同的局限。

ZFS 可以是一个极佳的选择，但它远非唯一的选择。ZFS 带有重大的附带条件，其中尤为突出的是与之相关的操作系统局限性；而且尽管它有许多益处，但其中即便有也极少是 ZFS 独有的，而且任何一个部门能从其中每一项益处中都获益的情况都非常罕见。与任何技术一样，都有需要做出的权衡。一种尺寸并不适合所有人。知道 ZFS 何时适合你的关键，在于理解 ZFS 是什么、关于它哪些是、哪些不是独有的、它的设计目标是什么、将一个存储栈与一个纯文件系统相比较会如何产生误导性的结果，以及哪些固有局限与它捆绑在一起。

当 Solaris 或 FreeBSD 是所选定的操作系统时，ZFS 是一个关键的考量因素，也是常见的选择。除极少数例外，绝不应为了 ZFS 而选择操作系统，相反，应当在选定操作系统之后，常常（但并非总是）选择 ZFS。除了最罕见的情况之外，都应由操作系统来驱动文件系统的选择。操作系统的选择远比文件系统的选择重要得多。

ZFS 可以在 Linux 上使用，但在那里它并不被视为一个企业级选项，而更像是一个用于实验的业余系统，因为没有任何企业厂商（如 Red Hat、Suse 或 Canonical）在 Linux 上支持 ZFS，而且 Linux 已经拥有出色的替代方案。也许有朝一日 ZFS 会在 Linux 中被提升为一等的文件系统，但这并不被看好，因为 BtrFS 已经进入主线内核，并已被若干主要厂商纳入生产版本。

虽然 ZFS 会出现在绝大多数 Solaris 和 FreeBSD 的部署中，但这主要是因为它已经进入了默认文件系统的位置，而不是因为它在那些情况下明显是更优越的选择、甚或是经过了批判性的评估。在它原生且受支持的地方，ZFS 完全适合作为一个通用文件系统。

ZFS 的主要用例是什么？

ZFS 的设计目标和主要用例，是为 Solaris 和 FreeBSD 开放存储系统服务，要么向其他服务器提供共享存储，要么作为本地安装应用程序的海量数据仓库。在这些情况下，ZFS 对可扩展性和数据完整性的专注才真正大放异彩。ZFS 在很大程度上偏向于大型和企业规模的部门，而通常远离在中小型企业领域的适用性——在那里，Solaris 和 FreeBSD 技能以及大规模存储需求都很罕见。

参考：http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1