进步与缺憾 资深开发者讲解苹果新文件系统

前言

APFS，也就是 Apple File System（苹果文件系统），它的开发从 2014 年开始，Dominic Giampaolo 为首席工程师。APFS 不基于已有的东西，而是苹果从头打造的一个独立的系统。当 Giampaolo 被问到他有没有从 BSD 的 HAMMER，Linux 的 btrfs 或 OpenZFS 这些现代文件系统那里得到设计灵感时 —— 毕竟 APFS 想要实现的和它们的部分功能很相似 —— Giampaolo 解释说为了避免受到过多影响，他虽然知道它们，但并没有深入去了解。

Giampaolo 夸赞 APFS 的测试团队“是典范性的”，这一点尤为关键。业界流传一句话是，文件系统要走向成熟需要十年时间，而就我在 ZFS 上的经验，这话多多少少是正确的。苹果想要仅凭三、四年的发展就将 APFS 推广开来，那就一定要让它加速成熟起来。

还债

当 Mac 512K 还是苹果的旗舰级产品的 1985 年，HFS 文件系统就出现在了人们的眼前。HFS+ 作为它的重要更新，于 1998 年随着拥有 4GB 硬盘的 G3 PowerMacs 一起到来。自那时候起，家用电脑的存储能力可以说已经增长了超过千倍。为了对应不同的设备，HFS+ 也被分成了多个竞争的方向（据说 iOS 团队弄了个自己的 HFS 变体，做得太隐蔽甚至 Mac OS 团队都不知道），拥有不同的功能。不得不说 HFS+ 已经变得老旧而混乱了。更重要的是，它缺少了大多数操作系统为企业打造的重要特性，如纳秒时间戳、校验和、快照、稀疏文件支持等，这些都是理论上必须要有的基础成本。APFS 填补了这个空白，顺便还加上了对大型设备的支持。

APFS 最重要的变化在于它解决了 HFS+ 不可持续的问题，这是苹果一直以来所背负的技术债务。它统一了所有的变体，带来了期盼中的特性。总的来说，苹果从代码开始重新打造了自己的文件系统。

不过在 APFS 的特性列表里，压缩功能却消失了，从理论上说它要实现并不困难。当开发团队被问到为什么不做压缩功能的时候，他们用一种苹果特有的方式 —— 既不确认也不否定 —— 表示认同，并且强烈暗示说这是值得期待的。所以如果 APFS 公共版本里拥有压缩功能，并不会让人感到奇怪。

加密

加密很明显是 APFS 的核心特性，不同的设备对它的需求也不一样。举个例子，iPhone 要求的是文件系统中存在多个密钥，而笔记本电脑则希望有基于每个用户的密钥。你在 WWDC 上可以听到很多次“创新”这个词，但 APFS 在加密方面配得上这个词。它支持文件系统中以下几种不同的加密方案：

- 不加密

- 对应元数据和用户数据的单一密钥

- 对应元数据、文件，甚至是文件一部分的多个密钥

多密钥加密机制尤其适用于移动设备，因为它的所有数据都可能会被加密，然而解锁手机本身就需要额外的密钥和额外的数据。可惜的是这个机制在 macOS Sierra 第一个 beta 上似乎并没有作用（使用 diskutil 命令指定生成一个加密的新卷时，文件系统报告说没有加密）。

关于加密，我注意和 diskutil 相关的特性：当使用 diskutil 创建一个新卷后，APFS 支持安全地即时擦写文件系统。不过 APFS 会警告你这可能导致数据损坏，除非在命令行输入“-IHaveBeenWarnedThatAPFSIsPreReleaseAndThatIMayLoseData”才能继续 —— 这可不是瞎编。这或许意味着用户可以建立一个无法从 APFS 中提取的文件系统密钥。安全擦写只需要删除密钥即可，不需要为了确保完全的清除而打乱整个硬盘。多个 iOS 文档指出这个功能需要特殊的硬件。有趣的是这对于 macOS 来说究竟意味着什么。不管怎么说，不要让 FBI 或者 NSA 知道这件事，OK？

快照及备份

APFS 带来了一个呼声相当高的文件系统特性：快照。快照功能让你能够保留文件系统特定时刻的状态，使得在修改文件系统的同时保留旧数据。它实现了这个功能，却又很高效地节省了空间。文件系统能够追踪变化，只有新的数据才会占据额外的空间。这对于备份工作来说有着相当高价值的潜力，因为你可以有效地追踪自上一次备份以来数据的变化。

ZFS 系统拥有快照功能和序列化机制，使得它可以有效地进行备份或进行远程传输。APFS 能够做到这点吗？Giampaolo 的回答是可能不行。ZFS 能够发送所有已更改的数据，而 Time Machine 则拥有类似排除列表这样的东西。这个不足是可以解决的，但我们要观察的是苹果会怎么做。APFS 目前仍不兼容 Time Machine，因为它缺乏对目录硬链接的支持，这个让人烦躁的问题可能源于 Time Machine 那被人质疑的可靠性。希望 APFS 以后能够针对 Time Machine 备份打造高效的序列化机制。

当 APFS 的开发经理 Eric Tamura 在 WWDC 上展示快照时，它所需的工具却并不包括在 macOS Sierra 的 Beta 版中。我使用 DTrace（我对苹果从 OpenSolaris 移植来这个技术越发惊讶）找到了一个被称为 fs_snapshot 的东西，希望其他人能够逆向工程找到它的确切用途。

管理

APFS 带来的另一个新特性是“空间共享”，让跨越一台设备的单个 APFS“容器”能够拥有多个“卷”（文件系统）在其中。苹果将该功能与过去静态分配硬盘空间，以支持多个 HFS+ 的实例进行对比，这显得有些华而不实。ZFS 和 btrfs 都拥有相似的概念，即一个用有嵌套文件系统的共享存储池，以实现规划与管理。

在和 Giampaolo 及 APFS 团队其它成员的谈话中，我们讨论了多个卷是如何作为一个单元让用户可以实现快照和加密等操作的。你会希望多个卷可以符合那些设置的不同策略。举个例子，当你想要每天对系统进行一次快照和备份的时候，用来在休眠时保存内存数据的 /private/var/vm/sleepimage 不该需要理会，也不该备份。

空间共享看上去更像是一个操作上的细节，而且能够改变游戏规则的新特性。你可以将它视为一个拥有快照和加密操作的特殊文件夹。添加新卷会因出现未知错误（不知道 -69625 究竟是什么意思）失败，但使用一个更大的磁盘镜像可以解决这个问题。

空间效率

如今的文件系统发展趋势是要让数据存储更高效，以有效地增加设备的存储空间。最常用的做法是压缩和重复数据删除。后一个机制可以发现相同区块，然后避免将它们重复存储。这种技术对于文件服务器来说非常有利，因为许多用户或许多虚拟主机会拥有同一个文件的多个拷贝。不过这对苹果最在乎的单一用户或少量用户环境来说，似乎并不实用（没错，它们很类似服务器，但其本质却并非如此）。从我支持 ZFS 时学习到的痛苦经验中可以发现，要做好是非常困难的。

苹果在空间效率方面较为独特的贡献是文件和目录的恒定时间复制。顺便说一下，macOS 中的“文件”通常就指的是目录。这是一种方便的说法，让逻辑上关联的文件集合能够被视为不可分割的单元。在应用上右击，然后选择“显示封包内容”，你就能明白我的意思了。因此，我在下文中将使用“文件”而非“文件或目录”，让有耐心读到这里的读者们稍微不那么痛苦。

在 APFS 中，如果你在相同的文件系统（也可能是相同的容器，之后再仔细谈这个）里复制一个文件，事实上并不产生重复数据，取而代之的是恒定大小的元数据被更新，并共享硬盘中已有的数据。这类复制中发生的变动会导致新空间的分配，这被称为写时拷贝，即“Copy on Write”。btrfs 同样支持这样的技术，并将其命名为 reflinks，也就是基于引用链接。

除了 btrfs 外，我还没在其他文件系统中看到类似的功能。虽然苹果进行了很好的演示，但我还是有些怀疑它的实际用处。在设备间复制文件（比如使用 U 盘来共享）的话，根据数据大小肯定是要消耗不同的时间的。我为什么要在本地复制文件呢？唯一能够想到的用途，就是在写论文的时候创建“初稿”、“终稿”、“终稿修改”、“终稿改得不能再改”了。

从本质上来说文件类型有这三种：

- 每一次都被完全重写的文件，如图片、Office 文档、视频等

- 只会被添加的文件，如日志

- 基于记录结构的文件，如数据库文件

对于普通用户来说，大多数文件都属于第一类。因此，APFS 让我能够在复制文档的时候享受到空间共享带来的好处，然而当我保存新版本的时候，这种好处就荡然无存了。或许，这对于那些需要经常接触大型文件的用户来说会更有用，他们也能够想出更好的用法来。

就个人而言，我能用到的唯一一个地方就是把《权力的游戏》剧集放进 Dropbox 里了。眼下我可以选择做一份拷贝，或是将文件永久放进 Dropbox 文件夹中。克隆操作能够让事情更简单一些，但另一方面，硬链接（这是一种各个文件系统非常常用的功能，可以让一个文件出现在多个目录里）也能做到。

克隆可能会导致人们的困惑，因为复制一个文件虽然不占据空间，但这也意味着删除它释放不了空间。你就想象一下这个场景吧：想要删点儿文件释放一些空间，却发现你必须要一直追溯到文件克隆的源头，才能够真正把它删掉。

可惜 APFS 的工程师们似乎并不太考虑实用性的事情，在 WWDC 上他们向开发者们寻求建议，但提出的问题要么不太实用，要么太小众。如果他们的关注点在于通用的版本控制，那么我为苹果没能提出更优雅的解决办法感到惊讶。如果 APFS 能够实现一个对应每个文件的 Time Machine，毕竟它可以追踪任何文件的变化，这将会创造一种全新的文件类型，每一个更新版本都可以被自动透明地记录下来。你可以浏览之前的版本，翻阅历史，或是一次性删除过去的那些版本。其实苹果早在五年前就提出了类似的东西，但除非深入去研究否则我也发现不了。总的来说 APFS 可以简化使用流程，为所有的应用带来通用支持。

小贴士：Finder 复制指令可以使用节省空间的克隆操作，但命令行的 cp 却做不到。

性能

苹果宣称 APFS 已经对闪存进行了优化，闪存（NAND）就是在你 SSD 中的那个东西。苹果将闪存放进 iPod 和 iPhone 中，改变了计算机业，因此产生的大量需求让闪存的经济性发生了变化。消费者的转变对企业造成了冲击（这是常有的事），使得混合硬盘和纯闪存阵列开始崛起。十年前闪存的成本和 DRAM 一样高，现在它甚至能够挑战机械硬盘的市场份额了。

SSD 模拟普通机械硬盘的区块寻址方式，但它本质上采用的技术其实截然不同。最重要的不同之处是，磁介质媒体可以任意地去反复读写扇区，而闪存只能读写较小的页数据，擦写大区块。这种管理通过闪存转换层实现，也就是我们说的 FTL，这是一种能够让区块和页数据的操作表现得更像是机械硬盘的软件。FTL 和文件系统很相似，它能在区块和物理地址间创建一个虚拟映射（一个转换）。苹果如能掌控全局 —— 包括 SSD、FTL 和文件系统 —— 它就能够打造一些与众不同的东西，为这些部分的协作进行优化。不过 APFS 所做的，只是简单地编写成 NAND 更容易控制的模式。总的来说这个文件系统拥有面向闪存的特性，但并非纯为原生闪存界面而生的。

再说说更多和闪存有关的话题，APFS 还包含了对 TRIM 的支持。TRIM 是一种存在于 ATA 协议中的指令，允许文件系统通知 SSD（尤其是它的 FTL）某些空间已经被释放。SSD 需要不少可支配空间，如果拥有更多的话它的性能还会更好，因此它们的物理空间要比宣传的更多。举个例子，1TB 的 SSD 里只有 931GB 的可用空间，以符合业界对 1TB 的自利定义。拥有了更多的空闲空间，FTL 就可以将空间效率转化为性能和寿命。TRIM 对于文件系统来说逐渐变得重要，因此 APFS 毫不意外地支持了它。TRIM 的问题在于只有在可用空间存在时它才会发挥作用，当你的硬盘差不多满了之后它就对你一点用都没有了。我很怀疑 TRIM 能够为 APFS 用户提供心理安慰以外的任何用途。

另外 APFS 还很重视延迟的问题：苹果的第一要务是避免系统出现长时间的忙碌状态（视觉效果上就是 OS X 里那不停旋转的彩球）。APFS 解决问题的方式是，通过 I/O QoS 给予可见的用户请求更高的优先权，而那些时间紧迫性不强的后台活动则放在后面。这无论是对于用户，还是对一个拥有复杂功能的文件系统来说，都是有利的。

数据完整性

毫无疑问一个文件系统最重要的工作就是保持数据的完整 —— 这是我的数据，别丢了，也别改动。如果一个文件系统能够被完全信任，那么数据备份的唯一理由就只剩下生怕自己操作失误了。文件系统拥有如下几种机制来保证数据安全：

冗余

APFS 并没有牵涉到和数据冗余相关的内容。正如苹果的 Eric Tamura 在 WWDC 上说的那样，大多数苹果产品都只拥有一个单一的存储设备（比如逻辑 SSD）实现 RAID。取而代之的，冗余来自更底层，如 Apple RAID、硬件 RAID 控制器、SAN 网络存储，甚至是那个单一的存储设备本身。

顺带一提，我们要注意的是，采用 APFS的大多数苹果产品中的 SSD 包含了多个独立 NAND 新芯片。高端 SSD 会在设备中实现数据冗余，但代价是牺牲容量和性能。正如上文提到的，“专为闪存优化”的 APFS 其实在标准数据块设备接口之下并没有太多扩展。

另外，APFS 也让普通用户最常用的本地数据冗余方式失效了：文件复制。在 APFS 中复制文件事实上只创建了一个轻量级的克隆，而非真正的数据复制。设备的损坏有可能意味着两份“拷贝”都会损坏，而如果真正意义上的完全复制，损坏只会影响到一个。

完全一致性

计算机系统任何时候都可能会出错 —— 崩溃、BUG、断电，各种各样的原因 —— 因此文件系统需要具备预期能力，并能从这些事件中恢复过来。最老最老的办法就是准备一个特殊的功能，在启动的时候缓慢地检查并修复文件系统（fsck）。现在较新的系统则会采用始终一致格式，或缩小不一致窗口，以此来取代成本高昂的完全检查。

数据复写最有可能会产生不一致。如果文件系统需要在数个区域内进行复写，那就会出现一部分区域是新状态，另一部分代表之前的状态的情况。写时复制可以避免这种状况的出现，因为它总是分配新区域，然后释放旧区域以便重新使用，而非就地修改数据。APFS 据说采用了一种“全新的写时复制元数据框架”，首席开发者 Giampaolo 强调这种方法的新颖，但却不愿深入谈及细节。在主题演讲之后的谈话中，他明确表示 APFS 没有采用 ZFS 系统的机制，即在改动后的用户数据之上复制所有元数据，以实现单一的，细微级别的文件系统结构更新。

很惊讶看到 APFS 包含 fsck_apfs 命令，即使是在询问了 Giampaolo 之后我仍不确定它为何有必要存在。作为对比，我并不认为 ZFS 文件系统不采用 fsck（文件系统检查）会有什么问题，因为文件系统本身并不知道怎么去识别。但 Giampaolo 却想不通为什么 ZFS 要放弃 fsck，因此这可能只是个萝卜白菜的问题。

校验

在苹果没谈及的那些 APFS 新功能中，最值得注意的是校验了。有些数据被用以识别（并修正）数据错误，这类数据的摘要或总结就叫校验。这部分内容要说起来比较微妙。APFS 会对自身的元数据进行校验，而非用户数据。校验元数据的理由很有说服力：它和用户数据关联不大（因此校验并不消耗太多空间），而元数据的丢失会大概率导致数据丢失。举个例子，如果最高层目录的元数据损坏了，那么硬盘上所有的数据都很有可能会损坏，最终无法访问。正因为这样，ZFS 系统会备份元数据，最高层的元数据甚至会复制三份。

更有趣的问题在于 APFS 为什么不去校验用户数据。苹果的工程师们表示苹果的存储设备里有强大的 ECC（纠错码）保护。无论是 NAND 还是机械硬盘，都使用冗余数据来识别并纠正错误。他们强调苹果设备绝对不会返回错误的数据。NAND 还是用了额外的数据，如每 4KB 128 字节，保证错误都能够被识别和修复。设备的错误率足够低，可以视为在其寿命内不会出现错误。另外还有一些其他的设备出错，会使得冗余检查无效。SSD 里有大量部件，一旦作为消费者产品开始量产，它们很好自带端对端的 ECC 保护，使得数据可能会在传输过程中损坏。还有，SSD 复杂的固件可能会存在导致数据丢失的 BUG。

苹果的工程师们对我在位衰减（数据老化导致完整性悄无声息地流失）以及其他设备错误方面的经验很感兴趣。苹果在对其供应商的某些品控测试方面可以说是最严格的，我相信他们确实能够采购到最好的部件。苹果工程师宣传位衰减对于他们的设备来说并不是问题，但如果你的软件无法识别错误，那你就无法了解自己的设备究竟表现得怎么样。

总而言之，数据一致性是非常重要的。考虑到即使是那些昂贵的企业级设备也可能会丢失数据，如果 Mac 上有你非常在意的东西，用每 4KB 16 字节换取安全简直是太值得了。

擦洗

当数据逐渐老化，你可能就会想要检查一下是否存在位衰减，之前我们提到过的 fsck_apfs 可以做到这一点。需要注意的是 APFS 没有数据冗余也不校验用户数据，因此擦洗只能发现问题，但不能修复它们。

总结

我不确定苹果是不是想要用 APFS 完全取代 HFS+，但他们已经经过了一个拐点，使得继续维护并更新一个年龄超过 30 年的软件要比打造一个新的要花钱得多。APFS 正是基于这种观点的产物。

根据苹果所展示的内容，APFS 的核心设计目标可以总结为以下几点：

- 满足所有的消费者（笔电、手机、手表等）

- 加密是第一要务

- 将快照视为现代化的备份手段

这些目标都很棒，因为它们将会让所有的苹果用户都受益。根据它在 WWDC 上的演示，APFS 似乎已经开始上轨道了（尽管现在的 macOS Sierra Beta 还没有包含那么多的变化）。

在打造一个全新的文件系统的过程中，APFS 团队加入了一些人们期待的特性。HFS 诞生的那个年代，400KB 磁盘仍旧统治着世界。如何从 2014 年开始的文件系统都需要考虑大型的设备，还有 SSD —— 检查再检查。写时复制和快照是标配。通过 Finder 快速实现复制也不能算是走弯路。虽然实际使用效果仍然不确定，这不是关键问题所在，况且演示的内容还是很有趣的。人们不想看到 OS X 系统里那臭名昭著的旋转彩球，而 APFS 生来就是为了解决它的。

不过仍然有些设计目标是缺席或是被摆在次要地位的，比如性能、开放性和数据一致。压榨每秒输入输出操作或设备吞吐量对 watchOS 来说可能并不那么重要，但对一小部分 macOS 的用户而言却较为关键。当 APFS 真正到来的时候它会如何表现，观察这个问题是很有趣的。过早进行对比会误导大众，对 APFS 团队来说也不公平。

APFS 的开发文档里终结了开源的问题：“现在这个时间点上不提供开源支持。”我并不指望 APFS 能够开源，但仍然希望苹果能够给我们惊喜。如果 APFS 能成为世界级的产品，我希望能够在 Linux 和 FreeBSD 上看到它，这甚至可能会让微软放弃自己的 ReFS 计划。我个人在 OpenZFS 上的经验表明开源能够开启一条加速通往成功的道路。APFS 缺少用户数据校验和数据冗余实在是太可惜了。数据完整应该是文件系统的优先事项，我相信不仅仅是对服务器，对手表或手机来说都是如此。

APFS 文件系统将会是面向所有苹果设备上所有苹果用户的一次稳定性提升，它带来了显而易见的好处，也仍有一些缺憾。如今 APFS 已经被全世界开发者所分享，而开发团队或许正在仔细倾听所有人的意见。虽然苹果选择了花费数年的时间去重新打造，而非接纳已有的技术，它还需要时间去更加重视数据完整性和开放性。不管采用什么样的做法，我被苹果想要在 18 个月内让 APFS 完全普及的雄心打动了，这就是一次激动人心的转变。

访问:

苹果在线商店(中国)