写点什么

Apple 新发布的 APFS 文件系统对用户意味着什么

2016 年 7 月 07 日

2016 年 WWDC 大会上,Apple 除了公布 watchOS、tvOS、macOS 以及 iOS 等一系列系统和软件更新外,还公布了一个名为 APFS(Apple File System)的文件系统。

这一全新文件系统专门针对闪存 /SSD 进行优化(但依然可用于传统机械硬盘),提供了更强大的加密、写入时复制元数据、空间分享、文件和目录克隆、快照、目录大小快速调整、原子级安全存储基元,以及改进的文件系统底层技术,将全面应用于该公司旗下所有设备中。

为什么不继续使用 HFS+?

HFS 诞生于 1985 年,随后在 1998 年发布的 4GB 硬盘版本 G3 PowerMac 中引入了改进的 HFS+ 文件系统。从 1998 年 4GB 容量的传统 HDD 机械硬盘,到现在 TB 规模的 SSD 固态硬盘,HFS+ 已经招架不住存储领域的大量改变和创新。

经过长期发展,HFS+ 针对不同类型的设备衍生出不同功能的多种分支,但它毕竟太老、太混乱了。更重要的是,该文件系统不具备当今大多数企业所需要的一些基本功能,例如纳秒级时间戳、校验、快照、稀疏文件等。Apple 生态圈急需一种能够取代 HFS+ 的全新文件系统。

APFS 应运而生!在解决 HFS 面临的各种遗留问题同时,还对 HFS 的所有变体进行了统一,这是 Apple 从底层代码开始从零打造的全新文件系统。

APFS 概述

全新开发的 APFS 除了支持 HFS+ 的全部功能外,还在以下方面有了突出的改进:

  • 与使用 32 位文件 ID 的 HFS+ 不同,APFS 可支持 64 位索引节点(Inode)编号,借此一个卷最多可存储超过 900 亿亿个文件。
  • HFS+ 只能同时对整个存储设备的文件系统进行初始化,APFS 提供了一种可扩展存储块分配程序(Extensible block allocator),可对数据结构进行延迟初始化(Lazy initialization),进而大幅改善大容量卷的性能。
  • APFS 支持三种模式的加密:不加密;适用于元数据和用户数据的单密钥加密;以及适用于元数据、文件,甚至文件中特定部分的多密钥加密。

此外 APFS 还包含其他改善和新功能,例如稀疏文件、改进的 TRIM 操作,内建对扩展属性的支持等。

脱胎换骨的 APFS 已经具备与 BSD HAMMER Linux btrfs ,或 OpenZFS 等现代化文件系统不相上下的功能和特性。

数据加密

安全与隐私是 APFS 的设计基础。Apple 的很多设备和操作系统早已具备加密功能,OS X 10.7 Lion 开始提供全磁盘加密功能;iOS 4 开始可通过专用数据保护技术将每个文件使用一个专用密钥进行加密。APFS 对这两种功能进行整合,为文件系统元数据提供了一种统一的加密模式。

加密是 APFS 原生支持的特性,用户可以针对每个卷选择下列任何一种加密方法:不加密,统一用一个密钥加密,或多密钥加密(针对每个文件使用专用密钥加密,同时针对敏感的元数据使用一个单独的密钥)。多密钥加密可确保哪怕设备物理安全受到威胁,依然可以保障用户数据的完整性。取决于具体硬件,APFS 加密可使用 AES-XTS 或 AES-CBC 算法。

这种加密机制还实现了一个额外的功能:更为快速的数据擦除。通常情况下当用户从设备中删除文件后,可以通过市面上提供的很多(免费或收费的)反删除软件找回删掉的内容。为避免这种情况,以往如果需要删除包含机密信息的文件,或需要将存储过私密数据的设备退役给他人使用,必须首先使用抹掉功能擦除存储设备,并可能要将这一过程执行多遍。取决于存储设备容量,整个过程将耗费极多时间。

对于使用APFS 文件系统的存储设备,在启用加密功能后,安全擦除的过程将变得大为简便和快捷,不再需要耗费大量时间多次给存储设备填充随机数据,只需要删除加密所用的密钥即可。

快照和备份功能

快照功能可将文件系统的状态“固定”在创建快照的那一刻,并可在保留固定状态的同时继续访问和修改文件系统。这种技术可以只记录新增或改动的数据块,因此可以为文件系统创建多个快照,而无需担心会占用大量存储空间。备份工具(例如Time Machine)通常会使用该功能记录自从上次备份之后文件系统的改动情况,并可用于在不打断用户操作的前提下对数据进行更为高效的备份。

由于不支持目录硬链接,APFS 暂不兼容Time Machine,希望以后APFS 能够针对Time Machine 提供更高效的序列化机制。本届WWDC 上,APFS 的开发经理Eric Tamura 在演示APFS 的快照功能时使用了一个尚未包含在Beta 版macOS Sierra 中的工具,同时根据Apple 的介绍,目前尚未提供用于访问快照功能的API,期待在后续版本中这个技术能够尽快完善起来。

空间共享

APFS 包含一个名为“空间共享”的新功能,借助该功能,多个文件系统可以共享同一个物理卷上的同一块底层可用空间。也就是说,设备上的一个 APFS“容器”内部可以包含多个“卷”(文件系统)。HFS+ 需要为每个文件系统预先分配固定大小的容量,这种做法较为“僵硬”,而 APFS 的空间共享功能可以让用户在无需重分区的情况下动态、灵活地扩大或缩小卷容量。

在这样的设计下,APFS 容器内的每个卷都会显示同等的可用空间容量,而所显示容量会等同于该容器的可用存储空间总量。例如,假设有个容量 100GB 的 APFS 容器,其中包含已用 10GB 容量的卷 A 和已用 20GB 容量的卷 B,卷 A 和卷 B 都会显示自己有 70GB(100GB-10GB-20GB)的可用容量。

存储空间使用效率

现代化的文件系统往往会通过压缩和去重(Deduplication)等方式减小文件占用的空间量。压缩很好理解,去重是指找出大量文件中相同的数据块,并只将这样的块存储一次,在访问文件时,会根据实际情况动态“拼装”出最终的文件。这样的功能最适合保存大量用户文件或大量虚拟机映像的服务器环境。

APFS 可以用恒定的速度对多个文件和目录创建副本。举例来说,如果要在同一个文件系统(或同一个容器)内部复制文件,实际上并不需要为数据创建副本,只需要对文件的元数据进行适当的更新就可以让磁盘上存储的数据实现“共享”,此时相同的文件“实际体积”不变,但产生了两个副本,对任何一个副本进行改动则需要为其分配新的存储空间(这种方式也叫做“写入时复制”)。

文件基本可以分为下列三种类别:

  • 每次需要全面覆盖的文件,例如图片、Office 文档、视频等
  • 可以“附加”新内容的文件,例如日志文件
  • 使用基于记录结构的文件,例如数据库文件

对大部分普通用户来说,接触最多的可能就是第一种文件。在 APFS 的帮助下,可以将文档(例如体积为 10MB)复制多次,并借助空间共享功能节约存储空间的用量,但只要改动过其中任何一个副本,就需要为这个副本分配 10MB 空间。

这样的“克隆”有可能给用户造成一定的困扰。既然复制的文件不占用空间,那删除这些文件也不会释放出空间。

另外还需要注意一点:在 Finder 内复制文件会产生这样可以节约空间的“克隆”,但命令行中的 cp 命令还会使用以往的方式为文件创建完整的副本。

性能

APFS 专门针对闪存进行了优化。SSD 虽然可以模拟传统机械硬盘的“块”,但底层技术与机械硬盘截然不同。SSD 底层的管理工作是由一种名为闪存转换层(FTL,Flash Translation Layer)的软件负责处理的。FTL 与文件系统极为类似,可以在块地址和介质内部的位置之间创建虚拟映射(转换)。整个堆栈,包括 SSD、FTL,以及文件系统都由 Apple 控制,可以更有针对性地对不同组件进行优化。

此外 APFS 还提供了对 TRIM 的支持。TRIM 是 ATA 协议中的一个命令,可以让文件系统告诉 SSD(其实是指示 SSD 中的 FTL)某些空间是空闲的。可用空间越多,SSD 的性能表现会越好,甚至大部分 SSD 所拥有的存储容量会超过标称值。

举例来说,假设有一个 1TB 容量的 SSD,显示的可用空间总量为 931GB。在有更多可用空间的情况下,FTL 可以牺牲空间利用率换回更高性能和更长寿命。但 TRIM 的问题在于,只有在存在可用空间的情况下这个功能才会有用,如果磁盘即将装满,TRIM 不会为你带来任何效果。

性能方面,APFS 的延迟也有了大幅改善。APFS 可以通过 I/O QoS(服务质量)对不同的访问请求划分优先级,将用户可以立刻察觉的操作和后台活动区分对待。

数据完整性

确保数据完整性,可以说这是任何文件系统的首要目标。我把数据交给你,你别弄丢了,也别随意修改。但如果这一切真的能实现,我们又为什么要“备份”呢?为确保数据安全,文件系统通常会采取一系列机制。

冗余

大部分 Apple 设备只有一个存储设备(即一个逻辑 SSD),因此 RAID 之类的做法毫无意义。此时冗余是通过更底层的组件实现的,例如 Apple RAID、硬件 RAID 控制器、SAN,甚至“单一”存储设备本身。

但是也要注意,大部分可支持 APFS 的 Apple 设备中的 SSD 实际上是由多个或多或少相互独立的 NAND 芯片组成的。一些高端 SSD 会在内部实施一定的数据冗余,但需要付出容量和性能双双降低的代价。

此外 APFS 使得“复制文件”这一用户最常用的实现本地数据冗余的方法也失去了作用。APFS 中复制的文件实际上只是对文件创建了轻量级克隆,实际数据并没有重复保存,底层设备的故障会导致所有“副本”受损。

绝对一致性

计算机系统在任何时候都可能出故障:崩溃、Bug、断电等…… 文件系统必须能够预见到这种情况并从故障中顺利恢复。遇到这种情况,以前可能需要尝试着用专门的工具在系统启动前检查并修复文件系统(例如使用 fsck )。较为现代化的系统会使用某些“始终一致”的格式,或将不一致的可能尽量降低,以避免耗费大量时间执行完整的 fsck 检查。例如 ZFS 就可以在磁盘上构建一个新状态,然后通过一次原子操作从之前的状态以原子级方式过度到新状态。

覆盖写入数据是最容易造成不一致的操作。如果文件系统需要覆写文件的多个区块,有一定可能遇到一些区块已经代表新状态,但一些区块依然代表旧的状态。为避免这种问题,可以使用上文提到的写入时复制这一方式,首先分配新区块,随后释放旧区块使其可被再次使用,而不需要就地修改数据。APFS 实施了一种“全新的写入时复制元数据体系”,这种方式的新颖之处在于,APFS 并未使用 ZFS 机制复制已更改用户数据的所有元数据,只需要对文件系统结构进行一次原子更新即可实现。

校验

校验是一种针对数据进行的摘要会汇总,可用于检测(和纠正)数据错误。APFS 会对自己的元数据,而非用户数据进行校验。这种对元数据进行校验的做法理由非常充分:大部分元数据都与用户数据无关(因此校验不会耗费太多存储空间),而丢失元数据会有极大可能造成用户数据的丢失。距离来说,假设某个顶层目录的元数据出错,那么磁盘上的所有数据都有可能无法访问。也正是因此,ZFS 会对元数据创建副本(甚至对顶层元数据创建三重副本)。

但是完全不对用户数据进行校验,这种做法似乎更有趣。WWDC 上的 APFS 工程师称,Apple 设备的存储具备强大的 ECC 纠错保护。NAND 闪存 SSD 和磁介质机械硬盘都可以使用冗余数据检测和纠正错误。Apple 工程师认为,Apple 设备通常不会遇到数据错误。NAND 会使用额外的数据,例如每 4KB 页使用额外的 128 字节数据,借此检测和纠正数据错误。设备本身的误码率已经足够低,可以认为设备整个生命周期内都不会出现错误。还有一些设备错误可以通过文件系统的冗余机制避免。SSD 中包含大量组件,而大部分消费类产品中的 SSD 很少包含端到端的 ECC 保护,因此可能导致数据传输过程中出现错误。SSD 固件中也可能包含导致数据丢失的 Bug。

Apple 对于供应商的设备质量测试可能是最严格的,用户可以相信 Apple 产品使用了最高质量的组件。Apple 工程师认为,此类设备的用户无需担心比特衰减(Bit Rot,逐渐老化的数据会慢慢丧失完整性)的问题,但如果软件本身无法检测错误,用户当然不知道设备的具体情况如何。价值数百万美元的存储阵列所用的ZFS 也可能出现数据错误,那么Apple 设备中所用的TLC NAND 芯片(最便宜的NAND 芯片类型)凭什么就不会出错?别忘了就在不久前某些大容量iPhone 6 才刚刚因为存储问题而召回。

总结

Apple 是否能完全用 APFS 取代 HFS+,这一点还不确定,不过他们很可能已经到了这样一个转折点:继续维护并改进过了“而立之年”的软件,这样的做法可能比全新开发一套新的软件成本更高。APFS 就是这样一种权衡之后的产物。

根据 Apple 在 WWDC 上的介绍,APFS 的核心设计目标可能是这样的:

  • 让所有消费者(笔记本、手机、手表等)满意
  • 将数据加密作为头等要务
  • 为现代化备份方式提供快照功能

这些目标可以让所有 Apple 用户获益,从 WWDC 上的演示可知,APFS 似乎已经开始逐渐走上正轨(尽管测试版的 macOS Sierra 似乎还有一段路要走)。

APFS 开发文档中针对“开源”有一个小注解:“开源的实现目前尚不可用”。其实很多人并不指望 APFS 能够开源。但如果 APFS 能够成为世界领先的文件系统,用户肯定还是希望在 Linux 和 FreeBSD 中也能使用,也许到时候 Microsoft 也能停止在 ReFS 方面的研发。APFS 不针对用户数据进行校验,没有提供数据冗余机制,这些确实让人感觉遗憾,毕竟数据完整性应该是任何文件系统的头等要务,而无论这样的文件系统将用于手表或手机,或者服务器,文件完整性问题都应该重视起来。

目前 APFS 已经以开发者预览版的方式通过 OS X 10.12(macOS Sierra)提供给用户,预计将在 2017 年正式发布。

若要尝试该功能,可在升级至 macOS 10.12 后通过新增的 hdiutil 命令行工具创建 APFS 卷:

复制代码
$ hdiutil create -fs APFS -size 1GB foo.sparseimage

目前的测试版 APFS 有一些局限:

  • 无法用于启动磁盘。
  • 文件和目录名称大小写敏感。
  • 无法用于 Time Machine、FileVault 或 Fusion 驱动器。
  • 现有第三方工具需要更新才能支持 APFS。
  • APFS 文件系统的卷无法被 OS X 10.11 Yosemite 以及更早的版本识别。
  • APFS 卷可以通过 SMB 网络文件共享协议共享,AFP 协议已弃用,无法用于共享 APFS 卷。

感谢魏星对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016 年 7 月 07 日 19:0016203
用户头像

发布了 283 篇内容, 共 84.6 次阅读, 收获喜欢 34 次。

关注

评论

发布
暂无评论
发现更多内容

当dubbo多注册中心碰上标签路由

小楼

dubbo

Linux系统优化

桥哥技术之路

Linux

一次漫长的dubbo网关内存泄露排查经历

小楼

dubbo 内存泄露

LeetCode 前1000题二叉树题目系统总结

Yano

面试 算法 LeetCode 二叉树 刷题

MacOS配置网络命令

编程随想曲

macos network

Ledge:这可能是距今最好的『DevOps + 研发效能』知识平台

Phodal

DevOps 敏捷开发 软件开发 研发效能

Sentinel在docker中获取CPU利用率的一个BUG

小楼

Java sentinel cpu

一个工程师向电信公司的维权

身为程序员,怎么接私活赚外快?

爱看书的小代码

广告与数据算法系列1.1.1: 什么是广告

黄崇远@数据虫巢

互联网 算法 广告

零基础应该如何学习爬虫技术?

极客时间

Python 编程 爬虫

centos7.6操作系统安装

桥哥技术之路

Linux

IPFS 星际传输协议的入门(二)

AIbot

区块链 分布式数据库

什么是物联网中台

老任物联网杂谈

物联网中台 IOT Platform 物联网平台

在Kubernetes上运行SpringBoot应用

铁花盆

Docker Kubernetes Spring Boot

Django 中如何优雅的记录日志

AlwaysBeta

Python django Web 后端

用jdk8的stream实现斐波那契数列

编号94530

jdk stream 斐波那契 fibonacci

要不要重新认识一下递归与迭代?

西了意

编程

格局不行,有机会也抓不住

池建强

创业 格局 MacTalk

SpringBoot中如何优雅的使用多线程

读钓

Java spring Spring Boot

skywalking内存泄露排查

小楼

dubbo 内存泄露

Docker运行常用软件:MySQL,Redis,Nginx,RabbitMQ,Neuxs,Gitlab

读钓

MySQL nginx Docker gitlab

以为是青铜,没想到是王者的dubbo标签路由

小楼

dubbo

nacos的一致性协议distro介绍

小楼

nacos

如何在非 sudo 用户下运行 docker 命令?

愚一

Docker DevOps

MySQL死锁与Spring事务

Dean

MySQL

Apache Beam 大数据处理一站式分析

李孟

Java 大数据 数据中台 数据交换 Beam

思维导图学《Linux性能优化实战》

Yano

Linux 后端

记一次spring注解@Value不生效的深度排查

小楼

spring Spring Boot dubbo

项目实施要避免哪些坑?

顾强

项目管理

C++数组可以为变量吗

程序喵大人

c++ 互联网 编程语言

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

Apple新发布的APFS文件系统对用户意味着什么-InfoQ