在今年的 WWDC 大会上，苹果公布了一个为旗下所有 OS 打造的全新文件系统 APFS。尽管它在消费者眼中并不显眼，但作为取代现有 HFS+ 的方案，APFS 的出现势必会产生深远影响。曾经参与 ZFS 文件系统开发的 Delphix 公司 CTO Adam Leventhal 以一个开发者的角度来评价 APFS，分析我们即将会迎来什么：
前言
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 给予可见的用户请求更高的优先权，而那些时间紧迫性不强的后台活动则放在后面。这无论是对于用户，还是对一个拥有复杂功能的文件系统来说，都是有利的。
想了解一切关于Apple相关资讯
请扫二维码关注“威锋网”公众号
长按识别二维码
