大多数现代 Linux 发行版默认使用 ext4 文件系统，就像之前的 Linux 发行版默认使用 ext3、ext2，以及更早之前的 ext 一样。
如果您是 Linux 新手，或者文件系统新手，您可能会想知道 ext4 相较于 ext3 有什么优势。您可能还会想知道，考虑到 btrfs、xfs 和 zfs 等替代文件系统的大量新闻报道，ext4 是否仍在积极开发中。
我们无法在一篇文章中涵盖关于文件系统的所有内容，但我们将尽力让您了解 Linux 默认文件系统的历史、现状以及未来展望。
在准备这篇概述时，我大量参考了 Wikipedia 上关于各种 ext 文件系统的文章、kernel.org 上关于 ext4 的 Wiki 条目，以及我自己的经验。
ext 的简要历史
MINIX 文件系统
在 ext 出现之前，存在 MINIX 文件系统。如果您不熟悉 Linux 历史，MINIX 是一个非常小的类 Unix 操作系统，用于 IBM PC/AT 微型计算机。Andrew Tannenbaum 为了教学目的开发了它，并在 1987 年以印刷形式发布了其源代码！
opensource.com
虽然您可以仔细阅读 MINIX 的源代码，但它实际上不是自由和开源软件 (FOSS)。Tannebaum 书籍的出版商要求支付 69 美元的许可费才能运行 MINIX，这笔费用包含在书的成本中。尽管如此，这在当时仍然非常便宜，MINIX 的采用迅速普及，很快就超出了 Tannenbaum 最初仅仅将其用于教授操作系统编码的意图。在整个 1990 年代，您可以在全球的大学中找到蓬勃发展的 MINIX 安装——一位年轻的 Linus Torvalds 使用 MINIX 开发了最初的 Linux 内核，该内核于 1991 年首次发布，并于 1992 年 12 月在 GPL 许可下发布。
但是等等，这是一篇文件系统文章，对吧？是的，MINIX 有自己的文件系统，早期版本的 Linux 也依赖于它。与 MINIX 一样，它可以不客气地被描述为“玩具”级别的例子——MINIX 文件系统只能处理最多 14 个字符的文件名，并且只能寻址 64MB 的存储空间。在 1991 年，典型的硬盘驱动器已经是 40-140MB 的大小。Linux 显然需要一个更好的文件系统！
ext
当 Linus 埋头开发新兴的 Linux 内核时，Rémy Card 致力于第一个 ext 文件系统。ext 于 1992 年首次实现——仅在 Linux 首次发布一年后！——解决了 MINIX 文件系统最严重的问题。
1992 年的 ext 使用了 Linux 内核中新的虚拟文件系统 (VFS) 抽象层。与之前的 MINIX 文件系统不同，ext 可以寻址高达 2GB 的存储空间，并处理 255 个字符的文件名。
但 ext 的统治并没有持续多久，主要是由于其原始的时间戳（每个文件只有一个时间戳，而不是我们今天熟悉的 inode 创建、文件访问和文件修改的三个独立时间戳）。仅仅一年后，ext2 就取代了它。
ext2
Rémy 显然很快意识到了 ext 的局限性，因为他在一年后就设计了 ext2 作为其替代品。虽然 ext 仍然扎根于“玩具”操作系统，但 ext2 从一开始就被设计为商业级文件系统，其原则与 BSD 的 Berkeley Fast File System 相同。
Ext2 提供的最大文件大小为千兆字节级，文件系统大小为太字节级，使其在 1990 年代稳居大型文件系统之列。它很快被广泛采用，不仅在 Linux 内核中，最终也在 MINIX 中，以及通过第三方模块使其可用于 MacOS 和 Windows。
但仍然存在一些问题需要解决：ext2 文件系统，像 1990 年代的大多数文件系统一样，如果系统在数据写入磁盘时崩溃或断电，很容易发生灾难性损坏。随着时间的推移，它们还因碎片化（单个文件存储在多个位置，物理上分散在旋转磁盘上）而遭受严重的性能损失。
尽管存在这些问题，但 ext2 今天仍然在一些孤立的案例中使用——最常见的是作为便携式 USB 拇指驱动器的格式。
ext3
在 ext2 被采用六年后的 1998 年，Stephen Tweedie 宣布他正在致力于对其进行重大改进。这成为了 ext3，它在 2001 年 11 月被内核版本 2.4.15 的主线 Linux 采用。
opensource.com
在大多数情况下，Ext2 在 Linux 发行版中表现良好，但是——像 FAT、FAT32、HFS 和当时的其它文件系统一样——它在断电期间容易发生灾难性损坏。如果您在向文件系统写入数据时断电，它可能会处于所谓的不一致状态——在这种状态下，事情只完成了一半，也撤销了一半。这可能会导致丢失或损坏大量与正在保存的文件无关的文件，甚至可能导致整个文件系统无法挂载。
Ext3 和 1990 年代后期的其他文件系统，例如微软的 NTFS，使用日志来解决这个问题。日志是磁盘上的一个特殊分配区域，写入操作以事务的形式存储在那里；如果事务完成写入磁盘，则其在日志中的数据将提交到文件系统本身。如果系统在操作提交之前崩溃，则重新启动的系统会将其识别为未完成的事务，并将其回滚，就好像它从未发生过一样。这意味着正在处理的文件可能仍然会丢失，但文件系统本身保持一致，并且所有其他数据都是安全的。在 Linux 内核实现的 ext3 中，有三个级别的日志可用：journal、ordered 和 writeback。
- Journal 是风险最低的模式，在将数据和元数据提交到文件系统之前，先将其写入日志。这确保了正在写入的文件以及整个文件系统的一致性，但可能会显著降低性能。
- Ordered 是大多数 Linux 发行版中的默认模式；ordered 模式将元数据写入日志，但将数据直接提交到文件系统。顾名思义，此处的操作顺序是严格的：首先，元数据被提交到日志；其次，数据被写入文件系统，然后才将日志中关联的元数据刷新到文件系统本身。这确保了，在发生崩溃的情况下，与未完成写入操作关联的元数据仍然在日志中，并且文件系统可以在回滚日志时清理这些未完成的写入操作。在 ordered 模式下，崩溃可能会导致在崩溃期间正在积极写入的文件损坏，但文件系统本身——以及未积极写入的文件——保证安全。
- Writeback 是第三种——也是最不安全的——日志模式。在 writeback 模式下，与 ordered 模式一样，元数据被记录日志，但数据不被记录。与 ordered 模式不同，元数据和数据都可以以任何最有利于性能的顺序写入。这可以显著提高性能，但安全性要差得多。虽然 writeback 模式仍然保证文件系统本身的安全性，但在崩溃期间或崩溃之前写入的文件容易丢失或损坏。
与之前的 ext2 一样，ext3 使用 16 位内部寻址。这意味着，在 4K 块大小的情况下，它可以处理的最大文件大小为 2 TiB，最大文件系统大小为 16 TiB。
ext4
Theodore Ts'o（当时已经是 ext3 的首席开发人员）在 2006 年宣布了 ext4，两年后，它被添加到内核版本 2.6.28 的主线 Linux 中。Ts'o 将 ext4 描述为一种权宜之计技术，它显著扩展了 ext3，但仍然依赖于旧技术。他预计它最终会被真正的下一代文件系统所取代。
opensource.com
Ext4 在功能上与 ext3 非常相似，但带来了更大的文件系统支持、改进的抗碎片能力、更高的性能和改进的时间戳。
Ext4 与 ext3
Ext3 和 ext4 有一些非常具体的差异，我将在此处重点介绍。
向后兼容性
Ext4 专门设计为尽可能向后兼容 ext3。这不仅允许将 ext3 文件系统就地升级到 ext4；还允许 ext4 驱动程序以 ext3 模式自动挂载 ext3 文件系统，从而无需单独维护两个代码库。
大型文件系统
Ext3 文件系统使用 32 位寻址，将其限制为 2 TiB 文件和 16 TiB 文件系统（假设 4 KiB 块大小；某些 ext3 文件系统使用较小的块大小，因此限制甚至更大）。
Ext4 使用 48 位内部寻址，理论上可以在高达 1,000,000 TiB (1 EiB) 的文件系统上分配高达 16 TiB 的文件。早期版本的 ext4 仍然受到某些用户空间实用程序限制，文件系统大小最大为 16 TiB，但截至 2011 年，e2fsprogs 已直接支持创建 >16TiB 的 ext4 文件系统。例如，Red Hat Enterprise Linux 在合同上仅支持最大 50 TiB 的 ext4 文件系统，并建议 ext4 卷不超过 100 TiB。
分配改进
Ext4 在写入磁盘之前，在存储块的分配方式上引入了许多改进，这可以显著提高读取和写入性能。
区段 (Extents)
区段是连续物理块的范围（假设 4 KiB 块大小，最大可达 128 MiB），可以一次性保留和寻址。使用区段减少了给定文件所需的 inode 数量，并显著减少了碎片化，并在写入大文件时提高了性能。
多块分配
Ext3 对于分配的每个新块都调用一次其块分配器。当多个写入器同时打开时，这很容易导致严重的碎片化。但是，ext4 使用延迟分配，这使其能够合并写入操作，并就如何为尚未提交的写入操作分配块做出更好的决策。
持久预分配
当为文件预分配磁盘空间时，大多数文件系统必须在创建时将零写入该文件的块中。Ext4 允许使用 fallocate() 代替，它保证了空间的可用性（并尝试为其找到连续空间），而无需先写入它。这显著提高了流媒体和数据库应用程序的写入和未来读取写入数据的性能。
延迟分配
这是一个复杂且有争议的功能。延迟分配允许 ext4 等待分配实际将数据写入的块，直到它准备好将该数据提交到磁盘。(相比之下，ext3 会立即分配块，即使数据仍在流入写入缓存。)
随着数据在缓存中累积而延迟分配块，这允许文件系统在如何分配这些块时做出更明智的选择，从而减少碎片化（写入和稍后的读取）并显著提高性能。不幸的是，对于那些没有专门编写为在程序员想要确保数据已完全刷新到磁盘时调用 fsync() 的程序，它增加了数据丢失的可能性。
假设一个程序完全重写一个文件
fd=open("file" ,O_TRUNC); write(fd, data); close(fd);
对于旧式文件系统，close(fd); 足以保证 file 的内容将被刷新到磁盘。即使从严格意义上讲，写入不是事务性的，如果在文件关闭后发生崩溃，丢失数据的风险也很小。
如果写入不成功（由于程序中的错误、磁盘上的错误、断电等），则原始版本和较新版本的文件都可能丢失或损坏。如果其他进程在文件正在写入时访问该文件，它们将看到损坏的版本。如果其他进程打开了该文件，并且不希望其内容发生更改——例如，映射到多个正在运行的程序中的共享库——它们可能会崩溃。
为了避免这些问题，一些程序员避免完全使用 O_TRUNC。相反，他们可能会写入一个新文件，关闭它，然后将其重命名为旧文件
fd=open("newfile"); write(fd, data); close(fd); rename("newfile", "file");
在没有延迟分配的文件系统下，这足以避免上述潜在的损坏和崩溃问题：由于 rename() 是一个原子操作，它不会被崩溃中断；并且正在运行的程序将继续引用旧的、现在已取消链接的 file 版本，只要它们拥有该文件的打开文件句柄。但是，由于 ext4 的延迟分配可能会导致写入操作被延迟和重新排序，因此 rename("newfile","file") 可能会在 newfile 的内容实际写入磁盘之前执行，这再次引发了并行进程获取 file 坏版本的问题。
为了缓解这个问题，Linux 内核（自 2.6.30 版本起）尝试检测这些常见的代码情况，并强制立即分配相关文件。这减少了，但不能阻止，数据丢失的可能性——并且它对新文件没有任何帮助。如果您是开发人员，请注意：保证数据立即写入磁盘的唯一方法是适当地调用 fsync()。
无限子目录
Ext3 限制为总共 32,000 个子目录；ext4 允许无限数量。从内核 2.6.23 开始，ext4 使用 HTree 索引来缓解大量子目录带来的性能损失。
日志校验和
Ext3 没有校验和其日志，这给磁盘或控制器设备带来了问题，这些设备拥有自己的缓存，不受内核的直接控制。如果控制器或具有自己缓存的磁盘以无序方式执行写入操作，则可能会破坏 ext3 的日志事务顺序，从而可能损坏在崩溃期间（或在崩溃之前一段时间）正在写入的文件。
理论上，通过使用写入屏障可以解决此问题——在挂载文件系统时，您可以在挂载选项中设置 barrier=1，然后设备将一直到硬件层面都遵守 fsync() 调用。但在实践中，人们发现存储设备和控制器经常不遵守写入屏障——提高了性能（以及基准测试，在基准测试中，它们与竞争对手进行比较），但开启了本应避免的数据损坏的可能性。
对日志进行校验和允许文件系统在崩溃后的首次挂载时意识到其某些条目无效或顺序错误。这样就避免了回滚部分或顺序错误的日志条目的错误，并进一步损坏文件系统——即使存储设备撒谎并且不遵守屏障。
快速文件系统检查
在 ext3 下，当调用 fsck 时，需要检查整个文件系统——包括已删除和空文件。相比之下，ext4 将未分配的块和 inode 表的各个部分标记为未分配，允许 fsck 完全跳过它们。这大大减少了在大多数文件系统上运行 fsck 的时间，并且自内核 2.6.24 以来已实现。
改进的时间戳
Ext3 提供的时间戳精度为一秒。虽然对于大多数用途来说已经足够，但关键任务应用程序通常需要更精确的时间控制。Ext4 通过提供纳秒级的时间戳，使其可用于这些企业级、科学和关键任务应用程序。
Ext3 文件系统也没有提供足够的位来存储 2038 年 1 月 18 日之后的日期。Ext4 在此处添加了额外的两位，将 Unix 纪元 又延长了 408 年。如果您在公元 2446 年阅读本文，希望您已经迁移到更好的文件系统——但如果您仍然以 UTC 1970 年 1 月 1 日 00:00 以来的时间来衡量时间，我会 posthumously 非常非常高兴。
在线碎片整理
ext2 和 ext3 都不直接支持在线碎片整理——即在文件系统挂载时进行碎片整理。Ext2 包含一个实用程序 e2defrag，它的名称已经说明了它的作用——但它需要在文件系统未挂载时离线运行。（显然，这对于根文件系统来说尤其成问题。）在 ext3 中情况更糟——尽管 ext3 比 ext2 更不容易遭受严重的碎片化，但对 ext3 文件系统运行 e2defrag 可能会导致灾难性损坏和数据丢失。
虽然 ext3 最初被认为是“不受碎片化影响的”，但采用大规模并行写入进程到同一文件（例如 BitTorrent）的进程清楚地表明，情况并非完全如此。一些用户空间黑客和解决方法，例如 Shake，以某种方式解决了这个问题——但它们比真正的、文件系统感知的、内核级的碎片整理进程更慢，并且在各个方面都不太令人满意。
Ext4 通过 e4defrag 直接解决了这个问题，e4defrag 是一个在线的、内核模式的、文件系统感知的、块和区段级别的碎片整理实用程序。
正在进行的 ext4 开发
正如 Monty Python 瘟疫受害者曾经说过的那样，Ext4 “还没完全死！” 虽然 其首席开发人员认为它 只是通往真正 下一代文件系统 的权宜之计，但由于技术或许可问题，可能的候选者在一段时间内都无法准备好部署为根文件系统。
未来版本的 ext4 仍在开发一些关键功能，包括元数据校验和、一流的配额支持和大型分配块。
元数据校验和
由于 ext4 具有冗余超级块，因此对其中的元数据进行校验和处理，为文件系统提供了一种自行判断主超级块是否已损坏以及是否需要使用备用超级块的方法。即使没有校验和，也可以从损坏的超级块中恢复——但用户首先需要意识到它已损坏，然后尝试使用备用超级块手动挂载文件系统。由于在某些情况下，使用损坏的主超级块以读写模式挂载文件系统可能会造成进一步的损坏，因此即使对于经验丰富的用户来说，这也不是一个充分的解决方案！
与 btrfs 或 zfs 等下一代文件系统提供的极其强大的每块校验和相比，ext4 的元数据校验和是一个相当弱的功能。但总比没有好得多。
虽然听起来像是毋庸置疑的——是的，校验和所有东西！——但在事后将校验和添加到文件系统中存在一些重大挑战；有关详细信息，请参阅 设计文档。
一流的配额支持
等等，配额？！自从 ext2 时代以来，我们就有了这些！是的，但它们始终是事后才想到的，而且它们一直有点糟糕。可能不值得在此处深入探讨这些复杂的细节，但 设计文档 阐述了如何将配额从用户空间移动到内核，并以更正确和更高效的方式强制执行。
大型分配块
随着时间的推移，那些讨厌的存储系统变得越来越大。随着一些固态硬盘已经使用 8K 硬件块大小，ext4 当前对 4K 块的限制变得越来越限制。更大的存储块可以显著减少碎片化并提高性能，但代价是增加了“松弛”空间（当您只需要块的一部分来存储文件或文件的最后一部分时留下的空间）。
您可以在 设计文档 中查看详细信息。
ext4 的实际限制
Ext4 是一个健壮、稳定的文件系统，并且是 2018 年大多数人应该用作根文件系统的文件系统。但它无法处理所有事情。让我们简要讨论一下您不应对 ext4 抱有的期望——现在可能在将来也不应抱有期望。
虽然 ext4 可以寻址高达 1 EiB（相当于 1,000,000 TiB）的数据，但您真的、真的不应该尝试这样做。除了仅仅能够记住更多块的地址之外，还存在规模问题，并且 ext4 现在（并且可能永远不会）在超过 50-100 TiB 数据的情况下扩展得很好。
Ext4 也未能充分保证数据的完整性。尽管日志记录在 ext3 时代是一项巨大的进步，但它并没有涵盖许多数据损坏的常见原因。如果数据在已存储在磁盘上时损坏——由于硬件故障、宇宙射线的影响（是的，真的）或数据随时间的简单退化——ext4 无法检测或修复此类损坏。
在最后两项的基础上，ext4 只是一个纯粹的文件系统，而不是存储卷管理器。这意味着，即使您有多个磁盘——因此具有奇偶校验或冗余，理论上您可以从中恢复损坏的数据——ext4 也无法知道这一点或利用它来为您带来好处。虽然理论上可以在不丢失自动损坏检测和修复功能的情况下在离散层中分离文件系统和存储卷管理系统，但这并不是当前存储系统的设计方式，并且它将对新设计提出重大挑战。
备用文件系统
在我们开始之前，先警告一句：对于任何未构建到并直接支持作为您的发行版主线内核一部分的备用文件系统，请非常小心！
即使文件系统是安全的，如果内核升级期间出现问题，将其用作根文件系统也可能非常可怕。如果您对从备用媒体启动并在 chroot 环境中手动且耐心地摆弄内核模块、grub 配置和 DKMS 的想法不是极其舒适...请不要在对您重要的系统上使用非发行版直接支持的根文件系统。
可能有很多很好的理由使用您的发行版不直接支持的文件系统——但如果您这样做，我强烈建议您在系统启动并可用之后挂载它。（例如，您可能有一个 ext4 根文件系统，但将大部分数据存储在 zfs 或 btrfs 池中。）
XFS
XFS 在 Linux 下几乎与非 ext 文件系统一样主流。它是一个 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 万亿千兆字节）命名，因为它理论上可以寻址如此大的存储系统。
作为一个真正的下一代文件系统，ZFS 提供卷管理（在单个文件系统中寻址多个单独的存储设备的能力）、块级加密校验和（允许以极高的准确率检测数据损坏）、自动损坏修复（在冗余或奇偶校验存储可用时）、快速 异步增量复制、在线压缩等等。还有更多。
从 Linux 用户的角度来看，ZFS 最大的问题是许可。ZFS 根据 CDDL 许可获得许可，CDDL 是一种半许可许可证，与 GPL 冲突。关于将 ZFS 与 Linux 内核一起使用的含义存在很多争议，意见从“它违反了 GPL”到“它违反了 CDDL”到“它完全没问题，只是尚未在法庭上进行测试”。最值得注意的是，自 2016 年以来，Canonical 已在其默认内核中内联包含 ZFS 代码，但迄今为止尚未受到法律挑战。
目前，即使作为我个人非常热衷的 ZFS 用户，我也不建议将 ZFS 用作根 Linux 文件系统。如果您想利用 Linux 上 ZFS 的优势，请在 ext4 上设置一个小的根文件系统，然后将 ZFS 放在您剩余的存储空间上，并将数据、应用程序以及您喜欢的任何内容放在其上——但在您的发行版明确
btrfs
Btrfs——B-Tree 文件系统的缩写，通常发音为“butter”——由 Chris Mason 在 2007 年他在 Oracle 任职期间宣布。Btrfs 的目标与 ZFS 大致相同，提供多设备管理、每块校验和、异步复制、在线压缩和 更多。
截至 2018 年，btrfs 作为标准的单磁盘文件系统相当稳定且可用，但不应依赖它作为卷管理器。与 ext4、XFS 或 ZFS 相比，它在许多常见用例中都存在严重的性能问题，并且其下一代功能——复制、多磁盘拓扑和快照管理——可能非常 buggy，结果从灾难性地降低性能到实际的数据丢失不等。
关于 btrfs 的当前状态仍存在争议；SUSE Enterprise Linux 在 2015 年将其作为默认文件系统采用，而 Red Hat 则宣布从 2017 年的 RHEL 7.4 开始不再支持 btrfs。可能值得注意的是，在生产环境中，受支持的 btrfs 部署将其用作单磁盘文件系统，而不是像 ZFS 那样的多磁盘卷管理器——即使是群晖 (Synology)，在其存储设备上使用 btrfs，也是将其分层在传统的 Linux 内核 RAID (mdraid) 之上以管理磁盘。
16 条评论