现在主流的 Linux 发行版默认的文件系统都已经是 ext4 文件系统了，只有少数早一点的发行版还以 ext3、ext2 作为默认文件系统，再往回看，甚至默认 ext 文件系统的发行版也是存在的。

如果你刚接触 Linux ，接触到 Linux 文件系统时，那么你可能会问 ext4 相较 ext3 有什么优势，甚至可能想知道 ext4 是否仍然正处在积极开发的状态，毕竟当下其他文件系统似乎更受人们关注（例如： btrf、xfs、zfs ）。

由于篇幅原因，本文不会详细介绍文件系统的具体细节，我们将会从整个 Linux 文件系统的发展历史开始介绍，阐述各个文件系统的特点，以及未来的展望。

Ext 文件系统简介

MINIX 文件系统

在 ext 出现以前，就已经有了 MINIX 文件系统。如果你不了解 Linux 的历史，其实 MINIX 其实是 IBM PC/AT 微型计算机的一个非常小的类 Unix 操作系统。在 1987 年的时候， Andrew Tannenbaum 以教学目的开发它，并发布它的源代码（以打印到文档上的形式）。

虽然你可以仔细阅读 MINIX 的源代码，但它实际上并不是免费的开源软件（ FOSS ）。 Tannebaum 书籍的出版商需要 69 美元的授权费来运营 MINIX ，这也是此书的主要成本。即便如此，但这段时间的成本却非常低廉，并且 MINIX 被迅速广泛应用，很快就超过了 Tannenbaum 的初衷（简单的使用它作为教科操作系统）。到了90年代，你仍然可以在全世界范围内的大学里找到 MINIX 的安装程序，并且发展得很快。一位叫 Linus Torvalds 的年轻人使用 MINIX 开发了原始的 Linux 内核，该内核于 1991 年首次发布，并于 1992 年 12 月以 GPL 许可证发布。

但是，这是一篇关于文件系统的文章对吗？是的！ MINIX 有它自己的文件系统，并且 Linux 的早期版本也非常依赖于它。就像 MINIX 一样，它可能会不公平地被描述为一种玩具 —— MINIX 文件系统最多只能处理 14 个字符的文件名，寻址只支持 64 MB 的存储空间。在 1991 年的时候，常见的硬盘已经有 40—140 MB 的大小，Linux 显然需要更好的文件系统。

ext

当 Linus 开始激烈的开发刚刚兴起的 Linux 内核时， RemyCard 开发了第一个 ext 文件系统。这个文件系统于 1992 年最初发布。仅在 Linux 发布的一年后， ext 解决了 MINIX 文件系统最严重的问题。

1992 年的 ext 在 Linux 的内核中使用了新的虚拟文件系统（ VFS ）来作为抽象层。与之前的 MINIX 文件系统不同， ext 最多可以处理 2GB 的存储空间和 255 个字符的文件名。

但是 ext 的流行时间并不久，主要是因为它的文件时间戳记录方式太简陋（每个文件只有一个时间戳，而不是三个独立的时间戳用于记录 inode 的创建时间、文件访问时间，以及文件的修改时间）。但是一年之后， ext2 就干掉了 ext 。

ext2

Remy 很快就意识到 ext 的局限性，因此一年以后，它将 ext2 作为替代品。现在看来 ext 仍然源于“玩具”操作系统，但 ext2 一开始就被设计为商业级的文件系统，它的原理与 BSD 的 Berkeley Fast File System 相同。 Ext2 能支持达到千兆字节的最大文件和兆兆字节的文件系统，在 90 年代的 GNU 联盟计划中占有重要地位。它被迅速且广泛地被推广开来，无论是在 Linux 内核还是在 MINIX 中，甚至出现了第三方模块使其能够用于 MacOS 和 Windows 。

即便如此，仍然有很多需要解决的问题：同 90 年代的大多数文件系统一样， ext2 文件系统在数据写入磁盘时，如果系统崩溃或者断电，很容易发生灾难性的破坏。随着时间的推移，文件系统中大量的数据碎片会带来严重的性能损失。

这些问题至今仍然存在，但还是有人用 ext2 文件系统，通常还有人在便携式 USB 存储器上使用这种文件系统格式。

ext3

1998 年，在 ext2 文件系统被使用了六年以后， Stephen Tweedie 宣布他正在大力改进它。这就有了接下来的 ext3 文件系统。 ext3 于 2001 年 11 月在 Linux 2.4.15 内核中开始被广泛使用起来。

在 Linux 发行版中 ext2 在各个场景下都表现得非常好，但和 FAT、FAT32、HFS 以及其他文件系统看来一样，仍然很容易在断电时发生严重的问题。如果在向文件系统写入数据时断电，那么可能会导致正在保存的文件丢失或损坏，甚至导致整个文件系统无法正常运行。

Ext3 以及其他 20 世纪 90 年代后期的文件系统（如 Microsoft 的 NTFS ）都是使用日志来解决这个问题。日志是磁盘上的特殊分配，写入文件可以看成是一次任务。如果该任务完成并写入磁盘，那么它在日志中的数据将写入固化到文件系统本身。如果在提交操作前系统发生了崩溃，那么重新启动的系统将会对其识别成未完成的任务，并对其进行回滚操作，就好像从来没有发生过一样。正在处理的文件可能会丢失，但文件系统本身能够始终保持一致，并且所有的其他数据都是安全的。 ext3 的 Linux 内核实现了三种日志级别： journal、ordered、writeback 。

• Journal 是风险最低的模式，在数据及元数据提交给文件系统之前将它们写入日志。这一操作确保了正在写入的文件以及整个文件系统的一致性，但会显著降低性能。
• Ordered 是大多数 Linux 发行版中的默认模式。 ordered 模式将元数据写入日志，而数据则是直接提交给文件系统。顾名思义，这项操作的顺序是严格规定的：首先，将元数据写入日志；其次，将数据写入文件系统，然后才将日志中的关联元数据刷新到文件系统本身。这能够确保在发生崩溃时，已经写入的不完整的相关元数据仍然存在日志中，同时文件系统可以在回滚日志中消除那些不完整文件的写入。在 ordered 模式下，崩溃可能会导致文件损坏或文件在崩溃期间被主动写入导致损坏，但是文件系统本身都可以保证未被主动写入的文件是安全的。
• Writeback 是第三种也是最不安全的日志模式，在 writeback 模式中，和 ordered 模式一样，元数据被记录，但数据不是。与 Ordered 模式不同的是，元数据和数据可以用任何的顺序进行编写，并且这都是有意义的，这样可以获得最佳的性能。虽然这样可以显著提高性能，但是不太安全。虽然 writeback 模式仍然为文件系统本身提供了安全保证，但是已经写入的文件在崩溃期间或之前容易发生损坏。

就像之前的 ext2 一样， ext3 使用 16 位内部寻址。当数据存储块大小为 4 时，它最大处理的文件大小为 2 TiB 和最大文件系统大小是 16 TiB 。

ext4

Theodore Ts'o （ ext3 主要开发者 ) 在 2006 年发布了 ext4 ，并于两年后在 Linux 2.6.28 中开始被广泛使用。 Ts'o 将 ext4 喻为权宜之计，它极大地扩展了 ext3 ，但仍然依赖于旧技术。他预计 ext4 终将会被下一代文件系统所取代。

Ext4 的功能与 Ext3 非常相似，带来了大文件系统支持、提高了碎片化的抵抗力和性能、改进了时间戳。

TODO

其他文件系统

首先这里我们需要注意一点：其他可选的文件系统不一定直接进入了你的 Linux 发行版使用的主线内核中，所以需要特别注意这一点。

一般来说，即使一个文件系统十分的可靠，当我们使用该文件系统作为 root 文件系统时，仍然可能由于内核升级时出现问题而造成灾难性的结果。所以，如果你不喜欢遇到这种情况下，不得不用其他引导媒介启动系统后，通过 chroot 进入原来系统并手动修复内核模块、grub 配置、DKMS 等这样复杂的操作修复系统，那就最好不要在 root 文件系统上存放对你重要的数据。

所以我们最好没有特殊需求时，不要使用你的发行版不直接支持的文件系统。如果你确实需要，最好是当你的系统可用时再使用其他文件系统。（比如，使用 ext4 作为你的 root 文件系统，用 zfs 或 btrf 存放你的数据）

XFS

XFS 作为一个非 ext 系列文件系统同样由 Linux 内核主线主持。XFS 是一个 64 位的高性能日志文件系统，它从 2001 年开始进入 Linux 内核。XFS 在大文件，高并发的情况下仍然具备非常高的性能。

Red Hat 企业版从 RHEL 7 开始以 ZFS 作为系统默认文件系统。但是，这样做仍然有一些缺点，特别对于家庭用户也小型企业用户来说尤其明显。想要扩展已存在的 XFS 文件系统非常的蛋疼，甚至有时，重新创建一个更大的 XFS 文件系统，再把数据复制过去来的更痛快。

虽然 XFS 非常的稳定和高性能，但这也不足以说我们可以放弃 ext4 全部推荐使用 XFS 。我们还是推荐使用 ext4 文件系统，除非你遇到大于 50 TB 的文件寻址，这个时候你就不能再用 ext4 了。（例如 RHEL 7 这样的发行版）

XFS 并不能像称为下一代的文件系统，它不像 zfs、btrf 以及 WAFL （Write Anywhere File Layout）那样。XFS 和 ext4 一样，可以说是这一代文件系统中非常出色的文件系统。

ZFS

ZFS 由 Sun Microsystems 开发，以 Zettabyte 命名（Zettabyte File System），相当于1万亿兆字节。它能存储1800亿亿（18.4×1018）倍于当前64位文件系统的数据。ZFS 的设计如此超前以至于这个极限就当前现实实际可能永远无法遇到。

ZFS 作为正真的下一代文件系统具有非常多的特点。ZFS 提供卷管理（能在单个文件系统中使用多个独立的存储设备）、块级别的校验和（极高的准确率检验数据损坏）、坏区自动修复（通过冗余或奇偶校验存储）、快速异步增量复制机制、以及内联压缩等诸多功能。

从 Linux 用户的角度来看， ZFS 最大的问题就是许可证的问题。ZFS 以 CDDL 许可证发布，这是一种与 GPL 许可证相互冲突的非完全开放许可证。关于在 Linux 中使用 ZFS 存在很多争议，到底是 GPL 违规了，还是 CDDL 违规了，又或者说完全没有问题目前还未在法庭上判决验证过。值得注意的是，Canonical 在 2016 年开始，已经将 ZFS 纳入其默认的内核中了，至今尚无法律挑战。

就目前而言，即使对于一名非常狂热的 ZFS 粉来说，我们也不推荐直接用 ZFS 作为 root 文件系统。如果你想要使用到 ZFS 的诸多优点，请在 ext4 上设置一个较小的 root 分区，其他剩余的存储使用 ZFS 文件系统。不论如何你够应该以 ext4 作为 root 文件系统，除非你是用的发行版明确的支持了 ZFS 。

btrfs

Btrfs 是 B-Tree Filesystem 的简写，最早在 2007 年 Chris Mason 任职于 Oracle 期间发布。Btrfs 旨在达到和 ZFS 一样的目标：多设备管理、块校验、异步副本更新、内联压缩等。

截止到 2018 年，Btrfs 可以说已经是相当的稳定了，完全可以用作标准的单磁盘文件系统，但是最好不要用它作为卷管理器。在很多场景下，btrfs 相比 ext4、xfs、zfs 在这种情况下会有严重的性能问题。并且在作为下一代文件系统应该具备的特性上来看，依旧存在许多的 bug ，非常容易产生性能问题，甚至数据丢失。

事实上， btrfs 的持续状态备受争议；SUSE Enterprise Linux 在 2015 年开始使用 btrfs 作为发行版默认文件系统，而 Red Hat 却宣告从 2017 年发布的 RHEL 7.4 起将不再支持 btrfs 。值得一提的是，生产环境下，btrfs 常常作为单个磁盘的文件系统，不作为像 ZFS 那样的多磁盘管理器。像 Synology 这样的公司，他们在存储设备上使用 btrfs ，但是在分层管理上却使用 Linux 内核 RAID 来管理磁盘。