就像之前的 Linux 发行版默认使用 ext3、ext2，以及更早的 ext 文件系统一样，大多数现代 Linux 发行版都默认使用 ext4 文件系统。
如果您是 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。
但仍然存在一些问题需要解决：像 1990 年代的大多数文件系统一样，如果系统在数据写入磁盘时崩溃或断电，ext2 文件系统很容易遭受灾难性的损坏。 随着时间的推移，它们还会因碎片（单个文件存储在多个位置，物理上分散在旋转磁盘周围）而遭受显着的性能损失。
尽管存在这些问题，但在今天的一些孤立情况下仍然使用 ext2——最常见的是，作为便携式 USB 拇指驱动器的格式。
ext3
在 ext2 采用六年后的 1998 年，Stephen Tweedie 宣布他正在努力对其进行重大改进。 这成为了 ext3，并在 2001 年 11 月通过内核版本 2.4.15 被纳入主线 Linux。
opensource.com
在大多数情况下，Ext2 对于 Linux 发行版来说做得很好，但是——像 FAT、FAT32、HFS 和当时的其它文件系统一样——在断电期间很容易发生灾难性的损坏。 如果在向文件系统写入数据时断电，文件系统可能会处于称为不一致的状态——在这种状态下，事情已被半完成和半未完成。 这可能会导致丢失或损坏与正在保存的文件无关的大量文件，甚至可能导致整个文件系统无法挂载。
Ext3 和 1990 年代后期的其它文件系统（例如 Microsoft 的 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）
区段（Extent）是一个连续物理块的范围（假设块大小为 4 KiB，则最多为 128 MiB），可以一次性保留和寻址。 利用区段（Extent）减少了给定文件所需的 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 00:00，1970 年 1 月 1 日以来的时间，我死后会非常非常高兴。
在线碎片整理
Ext2 和 Ext3 都不直接支持在线碎片整理——即在挂载文件系统时对其进行碎片整理。Ext2 包含一个实用程序 e2defrag，它的作用与名称所暗示的一样——但需要在文件系统未挂载时离线运行。（很明显，这对于根文件系统尤其有问题。）Ext3 中的情况更糟——尽管 Ext3 比 Ext2 更不可能遭受严重的碎片，但针对 Ext3 文件系统运行 e2defrag 可能会导致灾难性的损坏和数据丢失。
虽然最初认为 ext3 "不受碎片影响"，但采用大规模并行写入过程到同一文件的进程（例如，BitTorrent）清楚地表明情况并非完全如此。一些用户空间黑客和解决方法，例如 Shake，以一种或另一种方式解决了这个问题——但它们比真正的、文件系统感知的、内核级别的碎片整理过程更慢，并且在各个方面都不那么令人满意。
Ext4 通过 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，这是一种半宽松的许可协议，与 GPL 冲突。 关于在 Linux 内核中使用 ZFS 的影响存在很多争议，意见从“它违反了 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 相比，在许多常见用例中，它的性能存在重大问题，并且它的下一代功能——复制、多磁盘拓扑和快照管理——可能存在很多错误，结果从灾难性地降低性能到实际的数据丢失不等。
btrfs 的当前状态存在争议； SUSE Enterprise Linux 在 2015 年采用了它作为默认文件系统，而 Red Hat 宣布从 2017 年的 RHEL 7.4 开始将不再支持 btrfs。 值得注意的是，受支持的 btrfs 生产部署将其用作单磁盘文件系统，而不是像 ZFS 那样的多磁盘卷管理器——即使是群晖（Synology），在其存储设备上使用 btrfs，但也将其置于传统的 Linux 内核 RAID (mdraid) 之上以管理磁盘。
16 条评论