计算机的文件系统是一种存储和组织计算机数据的方法，它使得对其访问和查找变得容易，文件系统使用文件和树形目录的抽象逻辑概念代替了硬盘和光盘等物理设备使用数据块的概念，用户使用文件系统来保存数据不必关心数据实际保存在硬盘（或者光盘）的地址为多少的数据块上，只需要记住这个文件的所属目录和文件名。在写入新数据之前，用户不必关心硬盘上的那个块地址没有被使用，硬盘上的存储空间管理（分配和释放）功能由文件系统自动完成，用户只需要记住数据被写入到了哪个文件中。
严格地说，文件系统是一套实现了数据的存储、分级组织、访问和获取等操作的抽象数据类型（Abstract data type）。
目录
Linux的文件系统
Linux I/O 的基本组成：一切皆文件
Linux 中的各种事物比如像文档、目录（Mac OS X 和 Windows 系统下称之为文件夹）、键盘、监视器、硬盘、可移动媒体设备、打印机、调制解调器、虚拟终端，还有进程间通信（IPC）和网络通信等输入/输出资源都是定义在文件系统空间下的字节流。一切都可看作是文件，其最显著的好处是对于上面所列出的输入/输出资源，只需要相同的一套 Linux 工具、实用程序和 API。你可以使用同一套api(read, write)和工具(cat , 重定向, 管道)来处理unix中大多数的资源。
一切皆文件指的是对所有文件（目录、字符设备、块设备、套接字、打印机等）操作，读写都可用fopen()/fclose()/fwrite()/fread()等函数进行处理。屏蔽了硬件的区别，所有设备都抽象成文件，提供统一的接口给用户。虽然类型各不相同，但是对其提供的却是同一套操作界面。更进一步，对文件的操作也可以跨文件系统执行。
一切皆文件的不利之处在于，使用任何硬件设备都必须与根目录下某一目录执行挂载操作，否则无法使用。我们知道，本身 Linux 具有一个以根目录为树根的文件目录结构，每个设备也同样如此，它们是相互独立的。如果我们想通过 Linux 上的根目录找到设备文件的目录结构，就必须将这两个文件系统目录合二为一，这就是挂载的真正含义。
文件系统
VFS，是Linux 内核中的一个软件层，用于给用户空间的程序提供文件系统接口；同时，它也提供了内核中的一个抽象功能，允许不同的文件系统共存。系统中所有的文件系统不但依赖 VFS 共存，而且也依靠 VFS 协同工作。除了Linux标准的文件系统Ext2/Ext3/Ext4，Windows的vfat NTFS等，还有很多种文件系统，比如reiserfs，xfs，网络文件系统nfs。Linux通过VFS这个中间层对这些文件系统提供支持。
VFS，向上，对应用层提供一个标准的文件操作接口。向下，对文件系统提供一个标准的接口，以便其他操作系统的文件系统可以方便的移植到Linux上。
VFS为底层文件系统提供了一个尽量大的通用模型，使得这个模型包含所有文件系统功能的合集。因此VFS封装了底层文件系统的所有功能和抽象，VFS负责把应用层的请求转发给特定的文件系统。
目前的大部分 Linux 文件系统都默认采用 ext4 文件系统，正如以前的 Linux 发行版默认使用 ext3、ext2 以及更久前的 ext。
磁盘
磁盘指的是系统的存储设备，常见的有机械硬盘、固态硬盘等。如果发现应用程序要读的数据没有在页缓存中，这时候就需要真正向磁盘发起 I/O 请求。磁盘 I/O 的过程要先经过内核的通用块层、I/O 调度层、设备驱动层，最后才会交给具体的硬件设备处理。
- 通用块层。接收上层发出的磁盘请求，并最终发出 I/O 请求。它与 VPS 的作用类似。
- I/O 调度层。根据设置的调度算法对请求合并和排序。不能接收到磁盘请求就立刻交给驱动层处理。
- 块设备驱动层。根据具体的物理设备，选择对应的驱动程序，通过操控硬件设备完成最终的 I/O 请求。
EXT简史
MINIX 文件系统
在有 ext 之前，使用的是 MINIX 文件系统。如果你不熟悉 Linux 历史，那么可以理解为 MINIX 是用于IBM PC/AT 微型计算机的一个非常小的类 Unix 系统。Andrew Tannenbaum 为了教学的目的而开发了它，并于 1987 年发布了源代码（以印刷版的格式！）。
虽然你可以细读 MINIX 的源代码，但实际上它并不是自由开源软件（FOSS）。出版 Tannebaum 著作的出版商要求你花 69 美元的许可费来运行 MINIX，而这笔费用包含在书籍的费用中。尽管如此，在那时来说非常便宜，并且 MINIX 的使用得到迅速发展，很快超过了 Tannebaum 当初使用它来教授操作系统编码的意图。在整个 20 世纪 90 年代，你可以发现 MINIX 的安装在世界各个大学里面非常流行。而此时，年轻的 Linus Torvalds 使用 MINIX 来开发原始 Linux 内核，并于 1991 年首次公布，而后在 1992 年 12 月在 GPL 开源协议下发布。
MINIX 有自己的文件系统，早期的 Linux 版本依赖于它。跟 MINIX 一样，Linux 的文件系统也如同玩具那般小，MINIX 文件系统最多能处理 14 个字符的文件名，并且只能处理64MB 的存储空间。到了1991 年，一般的硬盘尺寸已经达到了 40-140 MB。很显然，Linux 需要一个更好的文件系统。
ext
当 Linus 开发出刚起步的 Linux 内核时，Rémy Card 从事第一代的 ext 文件系统的开发工作。ext 文件系统在 1992 年首次实现并发布， ext 使用在 Linux 内核中的新虚拟文件系统（VFS）抽象层。与之前的 MINIX 文件系统不同的是，ext 可以处理高达 2 GB 存储空间并处理 255 个字符的文件名，解决了 MINIX 文件系统中最糟糕的问题。但 ext 并没有长时间占统治地位，主要是由于它原始的时间戳（每个文件仅有一个时间戳，而不是今天我们所熟悉的有 inode、最近文件访问时间和最新文件修改时间的时间戳。）仅仅一年后，ext2 就替代了它。
ext2
Rémy 很快就意识到 ext 的局限性，所以一年后他设计出ext2 替代它。当 ext 仍然根植于 “玩具” 操作系统时，ext2 从一开始就被设计为一个商业级文件系统，沿用 BSD 的 Berkeley 文件系统的设计原理。ext2 提供了 GB 级别的最大文件大小和 TB 级别的文件系统大小，使其在 20 世纪 90 年代的地位牢牢巩固在文件系统大联盟中。很快它被广泛地使用，无论是在 Linux 内核中还是最终在 MINIX 中，且利用第三方模块可以使其应用于 MacOS 和 Windows。
但这里仍然有一些问题需要解决：ext2 文件系统与 20 世纪 90 年代的大多数文件系统一样，如果在将数据写入到磁盘的时候，系统发生崩溃或断电，则容易发生灾难性的数据损坏。随着时间的推移，由于碎片（单个文件存储在多个位置，物理上其分散在旋转的磁盘上），它们也遭受了严重的性能损失。尽管存在这些问题，但今天 ext2 还是用在某些特殊的情况下。最常见的是，作为便携式 USB 驱动器的文件系统格式。
ext3
1998 年，在 ext2 被采用后的 6 年后，Stephen Tweedie 宣布他正在致力于改进 ext2。这成了 ext3，并于 2001 年 11 月在 2.4.15 内核版本中被采用到 Linux 内核主线中。
在大部分情况下，ext2 在 Linux 发行版中工作得很好，但像 FAT、FAT32、HFS 和当时的其它文件系统一样， 在断电时容易发生灾难性的破坏。如果在将数据写入文件系统时候发生断电，则可能会将其留在所谓“不一致”的状态——事情只完成一半而另一半未完成。这可能导致大量文件丢失或损坏，这些文件与正在保存的文件无关甚至导致整个文件系统无法卸载。
ext3 和 20 世纪 90 年代后期的其它文件系统，如微软的 NTFS，使用 日志 来解决这个问题。日志是磁盘上的一种特殊的分配区域，其写入被存储在事务中；如果该事务完成磁盘写入，则日志中的数据将提交给文件系统自身。如果系统在该操作提交前崩溃，则重新启动的系统识别其为未完成的事务而将其进行回滚，就像从未发生过一样。这意味着正在处理的文件可能依然会丢失，但文件系统本身保持一致，且其它所有数据都是安全的。
在使用 ext3 文件系统的 Linux 内核中实现了三个级别的日志记录方式： 日记(journal)、 顺序(ordered)和 回写(writeback)。
- 日记：最低风险模式，在将数据和元数据提交给文件系统之前将其写入日志。这可以保证正在写入的文件与整个文件系统的一致性，但其显著降低了性能。
- 顺序：大多数 Linux 发行版默认模式；顺序模式将元数据写入日志而直接将数据提交到文件系统。顾名思义，这里的操作顺序是固定的：首先，元数据提交到日志；其次，数据写入文件系统，然后才将日志中关联的元数据更新到文件系统。这确保了在发生崩溃时，那些与未完整写入相关联的元数据仍在日志中，且文件系统可以在回滚日志时清理那些不完整的写入事务。在顺序模式下，系统崩溃可能导致在崩溃期间文件的错误被主动写入，但文件系统它本身 —— 以及未被主动写入的文件 —— 确保是安全的。
- 回写：第三种模式 —— 也是最不安全的日志模式。在回写模式下，像顺序模式一样，元数据会被记录到日志，但数据不会。与顺序模式不同，元数据和数据都可以以任何有利于获得最佳性能的顺序写入。这可以显著提高性能，但安全性低很多。尽管回写模式仍然保证文件系统本身的安全性，但在崩溃或崩溃之前写入的文件很容易丢失或损坏。
跟之前的 ext2 类似，ext3 使用 16 位内部寻址。这意味着对于有着 4K 块大小的 ext3 在最大规格为 16 TiB 的文件系统中可以处理的最大文件大小为 2 TiB。
ext4
Theodore Ts’o（是当时 ext3 主要开发人员）在 2006 年发表的 ext4，于两年后在 2.6.28 内核版本中被加入到了 Linux 主线。Ts’o 将 ext4 描述为一个显著扩展 ext3 但仍然依赖于旧技术的临时技术。他预计 ext4 终将会被真正的下一代文件系统所取代。
ext4 在功能上与 ext3 在功能上非常相似，但支持大文件系统，提高了对碎片的抵抗力，有更高的性能以及更好的时间戳。
ext3 和 ext4的差别：
- 向后兼容性
- ext4 特地设计为尽可能地向后兼容 ext3。这不仅允许 ext3 文件系统原地升级到 ext4；也允许ext4 驱动程序以ext3 模式自动挂载ext3 文件系统，因此使它无需单独维护两个代码库。
- 大文件系统
- ext3 文件系统使用 32 位寻址，这限制它仅支持 2 TiB 文件大小和 16 TiB 文件系统系统大小（这是假设在块大小为 4 KiB 的情况下，一些 ext3 文件系统使用更小的块大小，因此对其进一步被限制）。
- ext4 使用 48 位的内部寻址，理论上可以在文件系统上分配高达 16 TiB 大小的文件，其中文件系统大小最高可达 1000000 TiB（1 EiB）。
- 分配方式改进
- ext4 在将存储块写入磁盘之前对存储块的分配方式进行了大量改进，这可以显著提高读写性能。
- 区段
- 区段(extent)是一系列连续的物理块 (最多达 128 MiB，假设块大小为 4 KiB），可以一次性保留和寻址。使用区段可以减少给定文件所需的 inode 数量，并显著减少碎片并提高写入大文件时的性能。
- 多块分配
- ext3 为每一个新分配的块调用一次块分配器。当多个写入同时打开分配器时，很容易导致严重的碎片。然而，ext4 使用延迟分配，这允许它合并写入并更好地决定如何为尚未提交的写入分配块。
- 持久的预分配
- 在为文件预分配磁盘空间时，大部分文件系统必须在创建时将零写入该文件的块中。ext4 允许替代使用fallocate()，它保证了空间的可用性（并试图为它找到连续的空间），而不需要先写入它。这显著提高了写入和将来读取流和数据库应用程序的写入数据的性能。
- 延迟分配
- 这是一个耐人寻味而有争议性的功能。延迟分配允许 ext4 等待分配将写入数据的实际块，直到它准备好将数据提交到磁盘。（相比之下，即使数据仍然在往写入缓存中写入，ext3 也会立即分配块。）当缓存中的数据累积时，延迟分配块允许文件系统对如何分配块做出更好的选择，降低碎片（写入，以及稍后的读）并显著提升性能。然而不幸的是，它增加了还没有专门调用fsync()方法（当程序员想确保数据完全刷新到磁盘时）的程序的数据丢失的可能性。
- 无限制的子目录
- ext3 仅限于 32000 个子目录；ext4 允许无限数量的子目录。从6.23 内核版本开始，ext4 使用 HTree 索引来减少大量子目录的性能损失。
- 日志校验
- ext3 没有对日志进行校验，这给处于内核直接控制之外的磁盘或自带缓存的控制器设备带来了问题。如果控制器或具自带缓存的磁盘脱离了写入顺序，则可能会破坏 ext3 的日记事务顺序，从而可能破坏在崩溃期间（或之前一段时间）写入的文件。理论上，这个问题可以使用写入障碍(barrier)提高性能（和跟竞争对手比较的性能基准），但增加了本应该防止数据损坏的可能性。
- 对日志进行校验和允许文件系统崩溃后第一次挂载时意识到其某些条目是无效或无序的。因此，这避免了回滚部分条目或无序日志条目的错误，并进一步损坏的文件系统 —— 即使部分存储设备假做或不遵守写入障碍。
- 快速文件系统检查
- 在 ext3 下，在fsck被调用时会检查整个文件系统 —— 包括已删除或空文件。相比之下，ext4 标记了 inode 表未分配的块和扇区，从而允许fsck 完全跳过它们。这大大减少了在大多数文件系统上运行 fsck 的时间，它实现于内核6.24。
- 改进的时间戳
- ext3 提供粒度为一秒的时间戳。虽然足以满足大多数用途，但任务关键型应用程序经常需要更严格的时间控制。ext4 通过提供纳秒级的时间戳，使其可用于那些企业、科学以及任务关键型的应用程序。
- ext3 文件系统也没有提供足够的位来存储 2038 年 1 月 18 日以后的日期。ext4 在这里增加了两个位，将Unix 纪元扩展了 408 年。如果你在公元 2446 年读到这篇文章，你很有可能已经转移到一个更好的文件系统 —— 如果你还在测量自 1970 年 1 月 1 日 00:00（UTC）以来的时间，这会让我死后得以安眠。
- 在线碎片整理
- ext2 和 ext3 都不直接支持在线碎片整理 —— 即在挂载时会对文件系统进行碎片整理。ext2 有一个包含的实用程序e2defrag，它的名字暗示 —— 它需要在文件系统未挂载时脱机运行。（显然，这对于根文件系统来说非常有问题。）在 ext3 中的情况甚至更糟糕 —— 虽然 ext3 比 ext2 更不容易受到严重碎片的影响，但 ext3 文件系统运行 e2defrag 可能会导致灾难性损坏和数据丢失。
- 尽管 ext3 最初被认为“不受碎片影响”，但对同一文件（例如 BitTorrent）采用大规模并行写入过程的过程清楚地表明情况并非完全如此。一些用户空间的手段和解决方法，但它们比真正的、文件系统感知的、内核级碎片整理过程更慢并且在各方面都不太令人满意。
- ext4 通过e4defrag 解决了这个问题，且是一个在线、内核模式、文件系统感知、块和区段级别的碎片整理实用程序。
正在进行的 ext4 开发
虽然ext的主要开发人员认为它只是一个真正的下一代文件系统的权宜之计，但是在一段时间内，没有任何可能的候选人准备好（由于技术或许可问题）部署为根文件系统。在未来的 ext4 版本中仍然有一些关键功能要开发，包括元数据校验和、一流的配额支持和大分配块。
- 元数据校验和
- 由于 ext4 具有冗余超级块，因此为文件系统校验其中的元数据提供了一种方法，可以自行确定主超级块是否已损坏并需要使用备用块。可以在没有校验和的情况下，从损坏的超级块恢复 —— 但是用户首先需要意识到它已损坏，然后尝试使用备用方法手动挂载文件系统。由于在某些情况下，使用损坏的主超级块安装文件系统读写可能会造成进一步的损坏，即使是经验丰富的用户也无法避免，这也不是一个完美的解决方案！
- 与 Btrfs 或 ZFS 等下一代文件系统提供的极其强大的每块校验和相比，ext4 的元数据校验和的功能非常弱。但它总比没有好。虽然校验所有的事情都听起来很简单！—— 事实上，将校验和与文件系统连接到一起有一些重大的挑战.
- 一流的配额支持
- 配额？！从 ext2 出现的那天开始我们就有了这些！是的，但它们一直都是事后的添加的东西，而且它们总是犯傻。这里可能不值得详细介绍，但设计文档列出了配额将从用户空间移动到内核中的方式，并且能够更加正确和高效地执行。
- 大分配块
- 随着时间的推移，那些讨厌的存储系统不断变得越来越大。由于一些固态硬盘已经使用 8K 硬件块大小，因此 ext4 对 4K 模块的当前限制越来越受到限制。较大的存储块可以显著减少碎片并提高性能，代价是增加“松弛”空间（当你只需要块的一部分来存储文件或文件的最后一块时留下的空间）。
ext4 的实际限制
ext4 是一个健壮、稳定的文件系统。如今大多数人都应该在用它作为根文件系统，但它无法处理所有需求。让我们简单地谈谈你不应该期待的一些事情 —— 现在或可能在未来：
虽然 ext4 可以处理高达 1 EiB 大小（相当于 1,000,000 TiB）大小的数据，但你 真的 不应该尝试这样做。除了能够记住更多块的地址之外，还存在规模上的问题。并且现在 ext4 不会处理（并且可能永远不会）超过 50-100 TiB 的数据。
ext4 也不足以保证数据的完整性。随着日志记录的重大进展又回到了 ext3 的那个时候，它并未涵盖数据损坏的许多常见原因。如果数据已经在磁盘上被破坏 —— 由于故障硬件，宇宙射线的影响（是的，真的），或者只是数据随时间衰减 —— ext4 无法检测或修复这种损坏。
基于上面两点，ext4 只是一个纯 文件系统，而不是存储卷管理器。这意味着，即使你有多个磁盘 —— 也就是奇偶校验或冗余，理论上你可以从 ext4 中恢复损坏的数据，但无法知道使用它是否对你有利。虽然理论上可以在不同的层中分离文件系统和存储卷管理系统而不会丢失自动损坏检测和修复功能，但这不是当前存储系统的设计方式，并且它将给新设计带来重大挑战。
Linux下其他文件系统
XFS
XFS 与非 ext 文件系统在 Linux 中的主线中的地位一样。它是一个 64 位的日志文件系统，自 2001 年以来内置于 Linux 内核中，为大型文件系统和高度并发性提供了高性能（即大量的进程都会立即写入文件系统）。从 RHEL 7 开始，XFS 成为 Red Hat Enterprise Linux 的默认文件系统。对于家庭或小型企业用户来说，它仍然有一些缺点：重新调整现有 XFS 文件系统是一件非常痛苦的事情，不如创建另一个并复制数据更有意义。
虽然 XFS 是稳定的且是高性能的，但它和 ext4 之间没有足够具体的最终用途差异，以值得推荐在非默认（如 RHEL7）的任何地方使用它，除非它解决了对 ext4 的特定问题，例如大于 50 TiB 容量的文件系统。XFS 在任何方面都不是 ZFS、Btrfs 甚至 WAFL（一个专有的 SAN 文件系统）的“下一代”文件系统。就像 ext4 一样，它应该被视为一种更好的方式的权宜之计。
ZFS
ZFS 由 Sun Microsystems 开发，以 zettabyte 命名 —— 相当于 1 万亿 GB —— 因为它理论上可以解决大型存储系统。作为真正的下一代文件系统，ZFS 提供卷管理（能够在单个文件系统中处理多个单独的存储设备），块级加密校验和（允许以极高的准确率检测数据损坏），自动损坏修复（其中冗余或奇偶校验存储可用），快速异步增量复制，内联压缩等。
从 Linux 用户的角度来看，ZFS 的最大问题是许可证问题。ZFS 许可证是 CDDL 许可证，这是一种与 GPL 冲突的半许可的许可证。关于在 Linux 内核中使用 ZFS 的意义存在很多争议，其争议范围从“它是 GPL 违规”到“它是 CDDL 违规”到“它完全没问题，它还没有在法庭上进行过测试。”最值得注意的是，自 2016 年以来 Canonical 已将 ZFS 代码内联在其默认内核中，而且目前尚无法律挑战。
Btrfs
Btrfs 是 B-Tree Filesystem 的简称，通常发音为 “butter” —— 由 Chris Mason 于 2007 年在 Oracle 任职期间发布。Btrfs 旨在跟 ZFS 有大部分相同的目标，提供多种设备管理、每块校验、异步复制、直列压缩等。
截至 2018 年，Btrfs 相当稳定，可用作标准的单磁盘文件系统，但可能不应该依赖于卷管理器。与许多常见用例中的 ext4、XFS 或 ZFS 相比，它存在严重的性能问题，其下一代功能 —— 复制、多磁盘拓扑和快照管理 —— 可能非常多，其结果可能是从灾难性地性能降低到实际数据的丢失。
Btrfs 的维持状态是有争议的；SUSE Enterprise Linux 在 2015 年采用它作为默认文件系统，而 Red Hat 于 2017 年宣布它从 RHEL 7.4 开始不再支持 Btrfs。可能值得注意的是，该产品支持 Btrfs 部署用作单磁盘文件系统，而不是像 ZFS 中的多磁盘卷管理器，甚至 Synology 在它的存储设备使用 Btrfs，但是它在传统 Linux 内核 RAID（mdraid）之上分层来管理磁盘。
Mac OS 的文件系统
Mac OS 有很长的发展历史，其中经历过很多不同的文件系统。比较著名的文件系统：UFS，HFS+，以及 APFS。
UFS
1985 年，Steve Jobs 出走苹果，成立了 NeXT 公司。NeXT 公司基于 BSD 开发了 NeXTSTEP 操作系统，也就是现在大家熟悉的 Mac OS 的前身。NeXTSTEP 当时使用的文件系统是 Unix File System（UFS），这是当时最先进的文件系统，对后面的文件系统的设计产生了巨大的影响。
UFS，全称是 Unix File System，也被称作 Berkeley Fast File System。UFS 并不是苹果的原创。UFS 最早发表于 1984 年，他的作者是 Marshall Kirk McKusick 和 William Joy（Sun公司创始人）。UFS 可以说是现代文件系统的鼻祖，它的出现使得文件系统可以真正适用于生产环境。在 UFS 之前的文件系统最多只能使用 5% 的磁盘带宽，而 UFS 将这个数字提升到了 50%。这主要源于 UFS 中的两个设计：
- 将基础块大小从 1024 字节增加到 4096 字节
- 增加 Cylinder Group 的概念，优化数据和元数据在磁盘上的分布，减少读写文件时磁头寻道的次数（减少磁头寻道次数是 HDD 时代文件系统在性能优化上的一个主要方向）
UFS 的磁盘 layout 如上图。磁盘被分成了多个 Cylinder Group，每个 Cylinder Group 包含了一份 Superblock 的拷贝，以及这个 Cylinder Group 内部的元信息。由于操作文件时，通常都会先读取文件的 Inode，再操作文件的 Data Block。如果 Inode 和 Data Block 被放置在磁盘上相邻的位置，那就意味着不需要额外的寻道时间。
UFS 最早被实现在 BSD 系统上，此后，Sun 的 Solaris，IBM 的 System V，以及 HP-UX 等 Unix 操作系统都移植了 UFS。包括现在存储界的巨头 EMC 公司的很多存储产品，操作系统是 Unix 的，而文件系统则是基于 UFS 演进而来的。NeXTSTEP 作为 BSD 的变种，自然也采用了 UFS。Linux 上并没有 UFS 的实现，但著名的 ext2 文件系统在设计上很大程度借鉴了 UFS 的思想。而 ext3，ext4 又是基于 ext2 设计的扩展，也继承了 UFS 的思想。
1997 年 2 月，苹果完成收购 NeXT 公司，Steve Jobs 回归苹果。此后的 Mac OS 中仍然保留了对 UFS 的支持，直到 Mac OS X Lion 版本才取消对 UFS 的支持。
HFS+
苹果收购 NeXT 后，UFS 在 Mac OS 中作为默认文件系统的时间并不长。在 1998 年 1 月，苹果收购 NeXT 一年后，发布了 Mac OS 8.1，并搭载了 HFS Plus（HFS+） 文件系统，用于取代 UFS。从设计上来说，HFS+ 相对于他的上一代 HFS 有了不少改进，包括从 16 位升级为 32 位，支持 Unicode，最大文件支持 2^63 bytes 等等。HFS+ 最吸引人的功能，就是 Time Machine 了。使用过 Time Machine 功能的人都知道，这是一个非常炫酷且实用的功能，它可以将文件系统完整的回滚到之前的某一个时间点，可以用于对文件系统做备份，找回历史版本文件，也可以用于做系统迁移。
尽管如此，HFS+ 可以说是饱受争议的文件系统，甚至被 Linus 痛斥为有史以来最烂的文件系统。对 HFS+ 的批评主要有以下几个方面：
- 大小写不敏感（最新版本已支持大小写敏感，但默认配置仍未不敏感）
- 不支持对数据内容进行 checksum 校验
- timestamp 只支持到秒级
- 不支持并发访问
- 不支持快照
- 不支持 sparse file
- 使用 big-endian 进行存储
从技术角度来看，HFS+ 完全不像是一个现代文件系统，尽管它可以完成 Time Machine 这样炫酷的功能，但是和其他文件系统相比，技术过于落后，硬伤太多，例如大小写不敏感，不支持 Sparse File 等。这样 HFS+ 很难被称作是一个优秀的文件系统。
APFS
2017 年， 伴随着 Mac OS High Sierra 版本，苹果正式发布了 Apple File System。而在 2016 年的 WWDC 上，苹果就已经公布了 APFS 项目。为了和 AFS（Apple File Service）进行区分，采用了 APFS 作为缩写。
HFS 是 HFS+ 的前身，HFS 设计于 1985 年，距今已经有 30 多年的时间。当时的磁盘设备还是以软盘和磁盘为主，当时的 Mac 电脑的内存更是只有 512K。而随着 CPU，内存，存储介质技术的发展，今天我们使用的硬件和 30 年前相比，发生了巨大的变化。CPU 向多核方向发展，内存容量不断增加，单机已经可以支持 TB 级容量的内存，而存储介质也从 HDD 逐渐转为 SSD。硬件特性的变化，导致软件也需要不断调整设计和架构，才能跟得上硬件的节奏。HFS 经过 30 年的发展，技术生命已经走到了尽头，再对 HFS 进行改进已经非常困难了。
从 2014 年开始，在 Giampaolo 的带领下，苹果开始设计和开发新的文件系统，也就是 APFS。APFS 并没有基于已有的文件系统进行改造，而是从零开始构建，仅仅用了三年的时间就发布并上线，而通常一个文件系统从开发到稳定至少需要 10 年左右的时间。
苹果对新的文件系统提出了以下几个需求：
- 能够适应多种应用场景，从智能手表，智能手机，到笔记本电脑
- 确保数据安全可靠
- 能够充分利用多核 CPU 以及新硬件设备的并发性
同时，和 HFS+ 相比，APFS 提供了更多的功能：
- 保证 crash safe
- 64 位文件系统（HFS+ 是32 位文件系统）
- 支持 sparse file（HFS+ 不支持 sparse file！）
- 可扩展的元数据设计
- 支持快照和克隆
- 元数据支持 checksum 校验
Mac OS 的用户只要升级到 High Sierra 版本，文件系统会自动从 HFS+ 升级到 APFS。之所以可以从 HFS+ 直接升级到 APFS，是因为苹果设计了一个比较巧妙的升级过程。HFS+ 升级到 APFS 的过程如下：
- 按照 HFS+ 的格式，从磁盘中读取 Inode
- 在磁盘中查找空闲位置，并按照 APFS 的格式，将新的 Inode 写入到空闲空间中
- 修改磁盘的 Superblock，按照 APFS 的格式，将新的 Superblock 写入到磁盘中，新的 Superblock 将索引 APFS 的 Inode，并释放原有 HFS+ 的 Inode 所占用的空间
从性能上讲，尽管苹果宣称 APFS 为 SSD 做了优化，但有不少网站对 APFS 的性能进行了测试，发现 APFS 在 SSD 上的性能反而比 HFS+ 还有所下降。
Windows的文件系统
Windows下常见的文件系统格式有：FAT32、NTFS、exFAT
FAT32
Windows平台的传统文件格式通用格式，任何USB存储设备都会预装该文件系统，可以在任何操作平台上使用。Windows 95第二版首次引入，取代FAT16(支持文件最大容量2GB)，兼容性很好，但缺点是对文件大小有限制，不支持超过4GB的文件。所以，对于很多大型游戏、镜像文件、压缩包、视频，它是没有办法的。另外，FAT32格式硬盘分区的最大容量为2TB，FAT32已经落后于时代，能不用就别用。现在格式化U盘的时候，FAT32仍然是默认操作，Windows 10也是如此，更多是出于兼容性的保守考虑。
exFAT
最适合U盘的文件格式，是微软为闪存U盘量身定制的，性能和技术支持很先进，同时针对闪存优化保护，不会造成多余的伤害。
exFAT（Extended File Allocation Table File System，扩展FAT，也称作FAT64，即扩展文件分配表）是Microsoft在Windows Embeded 5.0以上（包括Windows CE 5.0、6.0、Windows Mobile5、6、6.1）中引入的一种适合于闪存的文件系统，为了解决FAT32等不支持4G及其更大的文件而推出。对于闪存，NTFS文件系统不适合使用，exFAT更为适用。对于磁盘则不太适用exFAT。主要好处包括：增强台式机/笔记本、移动设备之间的互操作能力、单文件最大16EB、剩余空间分配表改善空间分配行、同一目录下最多65536个文件、支持访问控制。最大的缺点是没有文件日志功能，这样就不能记录磁盘上文件的修改记录。
exFAT利用剩余空间位图来管理容量分配，提高删除性能，这对改善写入性能非常重要，尤其是对比NTFS。但要注意的是，在exFAT分区上安装Windows系统是不可能的。Windows Vista/7都非常依赖NTFS的文件许可等特性。不过由于微软授权机制的限制，exFAT的普及并不广泛，在消费电子领域的应用也不是特别多。
NTFS
Windows平台目前应用最广泛的格式，也是目前最好的，支持大容量文件和超大分区，而且有很多高级技术，包括长文件名、压缩分区、事件追踪、文件索引、高容错性、数据保护和恢复、加密访问等等。但是，NTFS仍然是针对机械硬盘设计的，会记录详细的硬盘读写操作，因此对于闪存（比如U盘、固态硬盘、SD卡等）会有很大的负担和伤害，容易影响寿命。闪存储存芯片读写次数是有限的，使用日志式文件系统的话，意味着所有对磁盘的操作都要记录日志。大量的小文件读写对于闪存的伤害是极大的，会缩短寿命。所以U盘不建议使用NTFS。
电脑使用固态硬盘时为什么依旧在使用为机械盘设计的NTFS文件系统？因为没有更好的选择！
ReFS
弹性文件系统（英语：Resilient File System，简称ReFS）。这是一个微软在Windows Server 2012中引入的专有文件系统，目的是成为NTFS之后的“下一代”文件系统。ReFS旨在克服NTFS被构想以来出现的重要问题，面向已改变的数据存储需求。ReFS的关键设计优势包括自动完整性检查和数据清理、避免需要运行chkdsk、防止数据衰落、内置硬盘驱动器故障和冗余的处理、集成RAID功能、数据和元数据更新切换到写时复制/分配、超长路径和文件名的处理，以及存储虚拟化和存储池、包括几乎任意大小的逻辑卷（与所用驱动器的物理大小无关）。从Win10 1709秋季创意者更新版开始，只有Win10企业版和Win10 Pro工作站版提供ReFS分区选项，其他Win10版本不再支持。
ReFS是与NTFS大部分兼容的，其主要目的 是为了保持较高的稳定性，可以自动验证数据是否损坏，并尽力恢复数据。如果和引入的Storage Spaces（存储空间）联合使用的话则可以提供更佳的数据防护。同时对于上亿级别的文件处理也有性能提升。
参考链接：
