一个ZFS开发者眼中的苹果最新文件存储系统APFS

Posted 2020-07-28 afatgoat

前言：

本文翻译自曾参与ZFS文件系统开发、现Delphix公司CTO，阿达姆 莱文索（Adam Leventhal），的一片博客文章：APFS详解(APFS in Detail)。

APFS文件系统是苹果公司准备2017年正式推出的继HFS+之后最新的文件系统，据现有公开资料显示，这个文件系统具备当代其它文件管理系统所具备的诸多先进功能，它将是统一所有苹果产品生态系统的唯一文件系统，可见它是苹果未来十数年最为重要的一个技术更新。(参考>1)

ZFS文件系统是广为业界知晓的当代先进文件系统之一，最早Sun公司（后被Oracle收购）为其Solaris操作系统开发，具有高存储容量、文件系统与卷管理概念集成、崭新的磁盘逻辑结构的轻量级文件系统，支持写时拷贝、快照与克隆、动态条带化、可变块尺寸、加密、数据压缩等特性。早于2004年发布，2005年并入Solaris系统的主干代码，2012年被用于生产环境，2013年推出稳定版本，它的发展从原型到成熟经历了近10年。(参考>2)

该文作者参与了ZFS的多个核心技术的开发，根据该文作者的经历，它对类Unix操作系统以及当代文件系统有着相当深刻的了解，通过本文，读者不仅可以对APFS的技术细节做一深入了解，同时也会了解一些文件系统的历史和发展，以及一些技术细节的差异。

那么作为一个具有如此深厚技术背景的他，对于APFS的评价，是褒是贬，批评多于褒奖，还是期望多余失望，是吹毛求疵还是对技术的精益求精？每个读者都会从自己的角度得到自己的感受，无论如何希望这能给我们带来诸多启发。

阿达姆简介

从现有的公开信息看，阿达姆最早被人们熟知是他作为DTrace的三人开发小组的一员，DTrace是当时2006年华尔街时报技术创新奖的金奖得主。他于2001年毕业后参加到当时Sun公司的Solaris核心开发团队，在Oracle收购Sun之后的2010年8月他离开了Oracle。在Sun和Oracle公司任职期间，他还参与了ZFS文件系统的多项核心技术的开发。(参考>3, >4)

博客原文

该博客分为六个部分，原文地址：
APFS in Detail: Overview
APFS in Detail: Encryption, Snapshots, and Backup
APFS in Detail: Space Efficiency and Clones
APFS in Detail: Performance
APFS in Detail: Data Integrity
APFS in Detail: Conclusions

翻译要点解释：
1. metadata（这里翻译成元数据）是Apple对其文件系统中系统结构数据（非用户数据的）的术语，atomic data（这里翻译成原子数据）是作者对ZFS文件系统相关数据的术语。
2. 在翻译中，由于中英文的习惯差异，以及作者的习惯，会将中文解释可能会比原文要多，用来解释上下文的文意。

---

博客正文

以下是原博客的翻译：

---

概述

苹果刚刚发布了一个新文件系统，它将会在明年被用于苹果所有操作系统变种中(macOS, tvOS, ios和watchOS)。目前媒体披露的多是基于苹果开发者文档的延伸。因为期望增加对其详情的了解，我参加了WWDC的APFS团队的演讲和问答部分。该团队的两位大将，吉阿姆保罗.多米尼克(Dominic Giampaolo)和田村.埃里克(Eric Tamura)，及其他团队成员，在一个拥挤的房间里进行了概述讲解和耐心的问题解答。基于这些数据和第一手的使用体验，作为一个既是苹果生态系统产品的使用者也是长期操作系统和文件系统开发者，我希望籍此对其做一个分析。

我将我的评论分为多个小节并在几个博客中发布，希望你在自己感兴趣的话题之间随意跳转或者直接跳转到结论（或者我的tweet总结）。（简短来说，APFS的-译者注）加密最好，而数据完整性最差。

基础

APFS, 全称Apple File System, 开始于2014年由多米尼克领导的技术团队，从最基础的开始独立开发的（在我之前的博客中说是基于核心存储CoreStoragede ,多米尼克更正了我的猜测）。我问多米尼克是否参考了其它现代文件系统的灵感，比如BSD的HAMMER, Linux的btrfs或者是OpenZFS(被Solaris，illumos, FreeBSD, Mac OS X,Ubuntu等等所使用)，所有这些都具有APFS所想要实现的类似功能（注意，从前苹果制作了一个相当完整的ZFS的移植，但显然多米尼克并没有参与）。多米尼克解释说，作为一个自称的文件系统开发者（它开发了BeOS的文件系统，很不幸地当初苹果购买了NeXTSTEP），他知道这些技术，不过为了不被过多影响，他并没深入研究它们。

他夸奖他杰出的团队，一个普遍知晓的古语也很重要：10年打造一个文件系统（译者注：作者言外之意，在接触的团队也无法打破这个规律）。基于我对ZFS的经验，多少验证了它的正确。苹果希望在未来3到4年内全部推广使用APFS，那么需要加速使之成熟。

偿还债务

1985年HFS文件系统被应用于当时苹果的旗舰产品Mac 512K（的内存，我靠!—-译者参考了谷歌翻译的结果，原文的Holly Smoke被翻译为“圣烟！”），后来HFS+作为其重要的更新于1998年在4GB硬盘的G3 PowerMac上发布。现在存储已经增长了千倍，HFS+也已经被不同的人在不同的设备应用于多种竞争方向（也就是，iOS开发团队偷偷摸摸自己制作了个HFS的变种，连Mac OS的团队都不太清楚），并带有不同的特性（日志，下小写不敏感等）。它太老了；太混乱了；更重要的是它缺少好多重要特性，这些特性是绝大多数操作系统为支持企业的基本特性，维基上面列出了比如纳秒时间戳、校验、快照和支持稀疏文件等。再加上对于大型设备的支持，自此你已经得到了一个APFS所需要支持的特性列表。

APFS首先是来偿还过去无法维护的HFS+技术债务的（这相当于：2001年时ZFS的开发是为了替换1977年的UFS），将所有变种统一化，引入需要的功能，当然了要从基础代码开始。

对于很多文件系统中常见的压缩功能，显然是APFS支持特性列表缺少的。从概念上它很简单，为了抚平多米尼克对BeOS的怀旧之情，我甚至回忆当初2000年时的面试，谈论压缩是如何改进整个系统性能的，因为I/O总比计算更加费时（现在尽人皆知，当初是一种新奇想法），我问其开发团队（我们在最初ZFS的开发就包含了这个特性）为什么没有这个特性？苹果员工尽管同意此观点，但不置可否地暗示着（-苹果特色-）这将是一个大家所期待的APFS的一个特性。但我并不会惊讶于压缩功能没有包含在公共发布本中。

加密

明显的加密是APFS的核心属性，需求来自于不同设备和多种需求，比如iPhone上需要文件系统支持多种密钥，以及笔电上基于用户的密钥等。在WWDC上多次听到的“革新”这个词，APFS所支持的支持多种不同的加密选择是最合适“革新”这个称呼的。它支持：

1. 不加密
2. 单一密钥的metadata和用户数据加密
3. 多密钥并分别对metadata、文件、甚至文件的一部分加密

多密钥加密对于移动设备更加有效，在所有数据都被加密的同时，用另外的密钥进行解密访问其数据。遗憾的是在beta版的macOS Sierra中并不支持（当使用diskutil命令生成一个加密的新卷后，文件系统却报告说该卷是未加密的）。

与加密相关的，在我尝试使用diskutil命令（除非你在命令行中加入选项:-IHaveBeenWarnedThatAPFSIsPreReleaseAndThatIMayLoseData，它会在输出中明示APFS的数据有可能损坏，并让用户确认）的时候发现，APFS支持线性时间加密文件系统删除(原文：“constant time cryptographic file system erase)，在diskutil输出中称作“可擦写”。这可能暗示：加密时的密钥不能从AFPS中再次导出，如果是这样，安全删除只需要删除该密钥，而不需要擦除、重复擦除整个硬盘的数据。多个iOS的文档都说这个功能需要特殊硬件支持，有趣的是对于macOS将会是什么样的特殊硬件。总之，不要告诉FBI或者NSA，大家同意吧？

快照和备份

APFS带来了最急需文件系统的特性：快照。一个快照可以让你保留文件系统在一个特定时刻的状态，保留旧数据的同时继续使用和更新。当然是有效利用空间基础上的，保留旧数据的同时有效地跟踪并只添加新数据，这个特性对于备份有潜在的特殊价值，也就是可以有效跟踪上次以来的数据更新。

ZFS包括了快照和串行化的机制，这使得备份文件系统和远程传输数据更加有效。APFS也会那样吗？多米尼克的回答是可能不会。ZFS只输出改变的数据，而时间机器可能有排他列表。虽然这是可以克服的，但让我拭目以待苹果会如何做。目前来说APFS与时间机器不兼容，因为APFS缺少对文件夹硬链接的支持，这是相当令人烦恼的与时间机器稳定性相关的措施。希望APFS可以有效的支持串行化功能来支持时间机器备份。

快照功能所需的工具没有包含在macOS Sierra的beta版本中，但项目经理埃里克.田村还是演示了快照功能。我使用DTrace（苹果从OpenSolaris一致过来的技术）发现该工具有个撩人的名字叫fs_snapshot。还是让他人进行反向工程发掘它的合适用途吧。

管理

AFPS具有另外一个新特性叫做空间共享(space sharing)。一个单独的APFS容器(container)内可以包括跨越设备的多个卷(Volumes)，苹果拿它与固定分配空间支持多HFS+的实例对比，令人感到华而不实，其实ZFS和btrfs都有类似的拥有嵌套文件系统的共享存储池概念。

我们与多米尼克和其它APFS成员，讨论了卷如何作为一个整体来由用户控制快照和加密，你可能希望多文件卷可以使用不同的策略，例如，可能需要每天快照和备份系统数据的同时，而无需备份也不用管（快照时也忽略）/private/var/vm/sleepimage（用于休眠时存储内存数据）文件。

与其说空间共享是关键特性，不如说是操作枝节，你可以将其看成是一个具有快照和加密的特殊文件夹–这也是为什么苹果的市场部门还没有招聘我的原因。（不幸，这个特性不包含在macOS Sierra的beta版中，无法生成一个多卷的容器，–这部分已经被原作者在博客中删除）添加卷会产生未知错误（你知道-69625是什么意思吗？）且一个超大的磁盘镜像也会导致该错误。

空间效率

现代文件系统的发展趋势是存储更加高效而非提高设备的存储空间大小。普通的做法是提供压缩（正如前面所提到的）和减少重复。减少重复的做法是当发现相同区块时避免重复存储，这一点对文件服务器有很大好处，多个用户和多个虚拟机可能有一个文件的多个副本，而对于单一用户或者极少用户的苹果使用者来说可能没多大用处（当然，它们是类服务器但是它们内心并不是）支持ZFS的经验也告诉我要做好是相当困难的。

苹果特殊的空间效率是线性时间文件和文件夹克隆。顺便说一下，对于macOS的文件很多情况下其实就是文件夹；对于逻辑上将多个关联的文件作为一个不可分割的单元的做法，其实是一种便利的做法，右键点击一个应用程序并显示包的内容，就知道我说的是什么了。因此，我将会使用“文件”，而不是“文件和文件夹”的称呼，以宽慰耐心读到这里的读者（字面作者的意思是使用简短的称呼，因为本文已经够长的了，其实是调侃一下）。

如果你在APFS的同一个文件系统（更有可能是同一个容器）中复制文件，不会产生重复数据，相反只是更新固定数量的metadata(元数据)并共享原先已存在的数据，对于任何一个复制版本的修改，都会产生新空间的分配（也就是写时复制，简称COW）。

虽然很好地演示了这个特性，但我还没有在其它文件系统中见过，我怀疑它的用途（更新：btrfs支持这功能，并称其为reflinks-基于引用的连接）。在设备之间复制数据（例如复制到U盘上）当然会消耗一定的时间。我为什么会在本地复制一个文件呢？我所能想到的一般用途是外行的版本控制：命题，命题的备份，旧命题，喝醉时编辑的命题保存。

基本上有三种文件：

• 总是被完全重写的文件：图像，微软Office文档和视频文件等
• 只添加的文件：就像log文件一样
• 基于记录结构的文件，比如数据库

对于普通用户，绝大多数文件是第一种。对于APFS来说我可以使用空间共享来复制文档，不过一旦保存新版本，这个功能的好处就不复存在了，但这个想法可能更好地适用于大型文件。

就个人而言，仅有的情况是将一个文件，比如权利的游戏剧集中的著作权法中“合理使用”一章的内容复制到Dropbox中的时候，现在我需要决定是复制还是彻底把该文件移到Dropbox中，克隆可能会更简单些，但是硬链接同样如此。

克隆功能可能产生潜在混乱，复制和删除一个文件都有可能不占用或释放任何存储空间。试想你需要将一个大型文件的所有版本都删除才能释放系统空间。

APFS的技术人员的脑子里似乎还没有多少实际应用例子；在WWDC中它们向开发者寻求建议（我所听到的最好的是VM(虚拟机)的副本问题；当然不是主流市场）。如果单独与一般的版本控制比较，我对Apple没有给出更优雅的解决方案感到惊讶。可以想见如果APFS准许一个用户使用基于文件的时间机器备份，搜寻任意文件的变更，这将为一个文件的每个版本自动地完全透明地产生一个新文件。你可以浏览以前版本、修改历史记录，或者一次性删除所有版本。实际上5年前Apple就引入过这个，但是我从来没有听说过，直到我搜索到这个帖子（看看你是否点击过“Browse All Versions…”）AFPS可以使之实施更简明，简化它的用途，对所有的应用都提供一般的支持。(APFS的特性)没有一个可以解决我的权力游戏的存储问题，当然我也不认为这是一个问题。
旁注：Finder的复制使用空间效率克隆技术，但是cp命令行却没有。

性能

APFS声称对闪存进行了优化。闪存(NAND)是你的高速SSD的内部部件。当Apple将闪存应用到iPod和iPhone的时候改变的产业界，大量的基础需求改变了闪存经济环境，（Apple）作为闪存消费者改变了对产业的影响（正如它所经常做的一样），使得混合硬盘和纯闪存阵列在市场中得到提升。10年前SSD就像DRAM内存一样贵，现在可以与硬盘争夺市场了。

SSD模仿传统硬盘的区块寻址方式，但是内部运作却完全不同。磁介质可以直接对每个扇区读写，闪存可以读取页数据，但只能删除一个大区块。这个操作由FTL闪存翻译层管理，它更像一个文件系统，生成区块与物理地址的虚拟对应，让对区块和页的操作看起来更像硬盘（的扇区操作）。Apple要完全控制SSD,FTL和文件系统，以完全不同的方式，优化这些部件以让它们协同工作。APFS所做的，其实是NAND所控制的，它是一个支持闪存特性的而不是一个专为闪存接口所写的、2016年你所期待的文件系统。

APFS包括了对TRIM的支持，TRIM是ATA协议中的命令，它准许文件系统通知SSD（准确说是FTL）一个空间是空闲的了，SSD需要特定的空闲空间来实现高性能。SSD有这比其宣称的更多物理容量，比如一个1TB的SSD实际有1TB（230-10243）字节的闪存，但它只显示有931GB的可用空间，以偷偷地贴近业界的自律标准1TB（10003=10亿字节）。利用这些多余空间，FTL可以实现高性能和长寿命。TRIM是文件系统所必须的功能，所以APFS支持它并不奇怪。TRIM的问题是只有当有空间释放时特别是对性能提升方面才有用。如果你的盘将近满了，TRIM无法为你做任何事。我怀疑TRIM可以为APFS带来任何益处，而只是对用户的安慰剂。

APFS也关注延时，Apple的第一目标是避免彩球死亡，APFS使用输入/输出QoS(服务品质保证)来给存取进行优先处理，也就是让可见的用户请求优先于那些非时间敏感的背景活动。这给用户带来无可置疑的的好处，同时也是一个成熟的文件系统所具备的能力。

数据完整性

毫无疑问一个文件系统最重要的任务是保护数据的完整性，“这是我的数据，别弄丢它，别随便改变它”。如果文件系统可以被完全的信任，那么备份的“唯一”理由就是傻X操作者了。文件系统有一些机制来保证数据安全。

冗余

APFS没有明说它提供数据冗余。正如田村.埃里克在WWDC上说的，绝大多数的苹果产品中只有一个存储设备（一个逻辑SSD）来实现RAID，其实冗余是更底层提供的，比如Apple RAID，硬件RAID，SANs，甚至是单一存储设备本身。

在一个内部说明中，众多运行APFS产品的SSD是多个独立NAND芯片组成的，高端SSD确实是在硬件内部实现冗余的，虽然牺牲了容量和性能。正如上面说的，针对SSD优化的APFS并没有从表面的数据块的接口而走得更远，其实是硬件本身的功能。

而且，APFS删掉了平时用户实现数据冗余的手段：复制文件。复制一个文件其实是产生一个轻量级的克隆，而不是数据复制。设备一旦损坏，所有的“复制品”都会被损坏，而本地完整复制可能只影响一个备份。

完全一致性

计算机系统可能随时出问题-崩溃、缺陷和掉电等等，所以文件系统能从这些情况下恢复数据。最老旧的方法是在启动时缓慢前行用工具检查并修复文件系统（的不一致性-译者注）（fsck，文件系统检查的缩写），更多的现代系统使用一致性格式或者缩小不一致窗口而降低全盘的fsck检测来达到同样的目的。例如ZFS，在磁盘上使用一个原子级的操作实现原子切换，生成一个新状态（确保一致性-译者注）。

擦写有可能产生不一致性，如果文件系统需要重写多个区域，而不同的区域可能是或新或旧状态（这造成不一致性)。写时复制(COW)就是避免这个冲突的，它总是先将新数据完全定位后，再释放旧数据空间，而不是在原有数据上做修改。据说APFS使用一种“新颖的元数据写时复制框架”，多米尼克强调了这个新颖性，但没有详细说。在稍后的交流中，他明确说APFS没有使用ZFS的那种更新文件系统结果的单一原子的机制去复制所有的改变了的数据的元数据。

令人惊讶的是APFS还有一个fsck_apfs的工具，即便在询问多米尼克之后也不能理解为什么需要这个工具。相比较ZFS的功能，文件系统本身自己知道问题所在，而不是靠fsck来发现文件系统问题。看似多米尼克有点被弄糊涂了，为什么ZFS放弃了fsck，所以可能只是我个人的想法吧。

校验

APFS的介绍中明显没有提到校验。校验是用数据摘要或者总结来检测（或修正)数据错误。这里讲得故事差别是很细微的。APFS只校验元数据而不是用户数据。只对元数据校验的理由是：元数据不大(而校验更不会占用多少空间)，而丢失它会造成数据丢失，如果高层元数据被破坏了，那么可能造成整个潘德数据无法读取。ZFS保存元数据的副本且对顶层元数据三重备份，也就是基于这个原因。

有趣的是（为什么）不校验用户数据。与我交谈的APFS工程师强调苹果存储设备自身有很强的ECC校验功能，SSD和磁盘介质都使用冗余检查和修正错误，他们强调苹果设备不会返回错误数据，NAND使用每4KB多余128字节来确保数据的可修正（正确性）（相比较ZFS使用32字节对每个512字节作校验，相较APFS的，两者相差不多，但注意基于模拟变量的不确定性使得SSD需要使用ECC校验）。在设备的生命周期中，设备产生一个比特错误的可能要比毫无错误的可能要高，而且还有其它的错误原因，比如无价值的文件系统冗余检查。SSD有多种市场，批量的消费级产品不提供端对端的ECC保证，使得数据在传输中可能出现错误，更何况固件本身还可能有错误造成数据丢失。

苹果员工们对设备衰减（数据会随时间丧失完整性）造成错误的经验很感兴趣。我见过很多的实例，设备没有报错但是ZFS正确地发现了错误。Apple对设备供应商有着苛刻的检查，我同意他们的产品是高质量的，他们声称Apple产品用户没有衰减的担忧，但如果你的软件不能检测到错误，你又如何知道设备的实际性能呢。ZFS在数百万元的阵列存储设备上发现过数据错误，如果不能发现Apple的TLC的NAND芯片的错误，那才是令人惊讶的，想想最近iPhone 6的存储问题的召回事件，其实Apple设备已经出过问题了。

对于关心在Mac数据的用户，在HFS中丢失数据的，甚至昂贵的企业级设备也丢失数据的用户，我会很愿意每4KB牺牲16字节（来换取数据的一致性），那只是牺牲1%的数据空间而已。

擦洗

随着时间推移你可能想检查一下设备衰减情况，看上去fsck_apfs可以做到；前面已经提到的，因为没有冗余和用户数据校验，那么擦洗(scrub)操作只有助于发现错误而不能修正错误，如果我是从Fry店买的便宜货而不是Apple的镀金高档货，这可以说服Apple改变主意（放弃苹果用户只会使用苹果配件的假设，而增加文件系统校验冗余等功能）吗？

总结

不知是不是Apple必须换掉HFS+，但他们已经给大家一种印象，维护一个30多年旧的软件比一个新的来得更高昂。APFS就是依据这个观点而生的。

依据Apple演示的来看，我推测它的核心目的是：
- 满足所有用户（笔电、手机和手表等用户）
- 加密是首位的
- 快照是近代化的备份

所有这些都会惠及所有Apple用户，基于WWDC的演示，APFS就在这条正轨上（虽然macOS Sierra的beta版还相差甚远）

实施一个新文件系统的过程中，APFS的团队添加一些所期待的功能。HFS产生于400KB软盘（那个过时的无处不在的保存图标）统治世界的时代，任何2014年之后的文件系统都应该考虑大型存储和SSD设备。写时复制(COW)和快照属于必备功能，把Finder中的复制命令变得更快些也不能算是走弯路，用户情形还不明了，推测结论是典型的废话，自寻麻烦的方法，但是依然是一个有趣的演示，彩球死机厄运确实是APFS想要避免的。

确实有些功能缺失，比如性能、开放性和完整性等。压榨设备吞吐率对于手表watchOS不是很重要，也只是对一小部分的macOS的用户有用，大家很感兴趣APFS发布时的性能表现（过早地对比是误导大众，对它的团队也不公）。APFS的开发者文档中有一条关于开源的：“此时不提供开源”，不期待APFS最近或者将来可以开源，Apple最好证明我是错的，如果APFS可以成为世界级的产品，我很愿意在Linux和FreeBSD中看到它的身影，甚至微软放弃自己的ReFS。就我的ZFS的经验来说，开源可以加速它成就卓越的步伐。真遗憾，APFS缺少用户数据的校验功能，不提供数据冗余。数据完整性是文件系统的任务之一，我相信这一点对于手表和手机与服务器是同样重要的。

APFS在稳定性上还需改进，对于所有Apple用户和所有设备都是这样。成功与失败机会相同，既然APFS已经分享给了世界与开发者们，Apple肯定已经通过过去数年中的讨论中得出自己从最基本开始做起的结论，而不是采纳一个现有的现代技术，那么数据完整新和开放性就是应该被重视的时候了。我被Apple想要在18个月内就使用APFS的目标所打动，无论过程如何，过渡将是令人兴奋的。

---

参考：

1. APFS: https://en.wikipedia.org/wiki/Apple_File_System
2. ZFS: https://en.wikipedia.org/wiki/ZFS
3. Adam Leventhal (programmer)：https://en.wikipedia.org/wiki/Adam_Leventhal_(programmer)#cite_note-4
4. Adam的Linkedin介绍：https://www.linkedin.com/in/adamleventhal?authType=name&authToken=usbc