Linux EXT4 文件系统简介

了解 EXT4 的历史、特性和最佳用途，并学习它与之前 EXT 文件系统迭代版本的区别。

图片来源

William Warby。Jason Baker 修改。Creative Commons BY-SA 2.0。

在之前关于 Linux 文件系统的文章中，我写了Linux 文件系统简介以及一些更高级的概念，例如一切皆文件。我想更详细地介绍 EXT 文件系统的具体细节，但首先，让我们回答一个问题：“什么是文件系统？” 文件系统包括以下所有内容

数据存储：任何文件系统的主要功能是成为存储和检索数据的结构化场所。
命名空间：一种命名和组织方法，提供命名和构建数据的规则。
安全模型：一种定义访问权限的方案。
API：用于操作文件系统对象（如目录和文件）的系统函数调用。
实现：实现上述功能的软件。

本文重点介绍列表中的第一项，并探讨元数据结构，这些结构为 EXT 文件系统中的数据存储提供逻辑框架。

EXT 文件系统历史

虽然 EXT 文件系统是为 Linux 编写的，但它的根源在于 Minix 操作系统和 Minix 文件系统，它们比 Linux 早大约五年，于 1987 年首次发布。如果我们回顾 EXT 文件系统家族从 Minix 根源开始的历史和技术演变，那么理解 EXT4 文件系统就容易得多。

Minix

在编写最初的 Linux 内核时，Linus Torvalds 需要一个文件系统，但当时不想编写一个。因此，他只是简单地包含了Minix 文件系统，该文件系统由Andrew S. Tanenbaum编写，并且是 Tanenbaum 的 Minix 操作系统的一部分。Minix是一个为教育目的而编写的类 Unix 操作系统。它的代码是免费提供的，并且获得了适当的许可，允许 Torvalds 将其包含在他的第一个 Linux 版本中。

Minix 具有以下结构，其中大多数结构位于生成文件系统的分区中

硬盘第一个扇区中的引导扇区，安装在该硬盘上。引导块包括一个非常小的引导记录和一个分区表。
每个分区中的第一个块是一个 超级块，其中包含定义其他文件系统结构并将其定位在分配给该分区的物理磁盘上的元数据。
一个 inode 位图块，用于确定哪些 inode 已使用，哪些是空闲的。
inode，它们在磁盘上有自己的空间。每个 inode 包含关于一个文件的信息，包括数据块的位置，即属于该文件的区域。
一个 区域位图，用于跟踪已使用和空闲的数据区域。
一个 数据区，其中实际存储数据。

对于两种类型的位图，一位代表一个特定的数据区或一个特定的 inode。如果该位为零，则表示该区域或 inode 是空闲的并且可用，但如果该位为一，则表示该数据区或 inode 正在使用中。

什么是inode？inode 是 index-node 的缩写，是磁盘上的 256 字节块，用于存储关于文件的数据。这包括文件的大小；文件用户和组所有者的用户 ID；文件模式（即访问权限）；以及三个时间戳，用于指定时间和日期：文件上次访问时间、上次修改时间和 inode 中的数据上次修改时间。

inode 还包含指向文件数据在硬盘驱动器上的位置的数据。在 Minix 和 EXT1-3 文件系统中，这是一个数据区或块的列表。Minix 文件系统 inode 支持九个数据块，七个直接块和两个间接块。如果您想了解更多信息，这里有一个优秀的 PDF，其中详细描述了Minix 文件系统结构，以及维基百科上对inode 指针结构的快速概述。

EXT

最初的EXT 文件系统（扩展文件系统）由Rémy Card编写，并于 1992 年随 Linux 一起发布，以克服 Minix 文件系统的一些大小限制。主要的结构性变化是文件系统的元数据，它基于 Unix 文件系统 (UFS)，也称为 Berkeley Fast File System (FFS)。我发现关于 EXT 文件系统的已发布信息非常少，可以验证，显然是因为它存在重大问题，并且很快被 EXT2 文件系统取代。

EXT2

EXT2 文件系统非常成功。它在 Linux 发行版中使用了多年，并且是我在 1997 年左右开始使用 Red Hat Linux 5.0 时遇到的第一个文件系统。EXT2 文件系统与 EXT 文件系统具有基本相同的元数据结构，但是 EXT2 更具前瞻性，因为在元数据结构之间留出了大量的磁盘空间以供将来使用。

与 Minix 一样，EXT2 在其安装的硬盘驱动器的第一个扇区中有一个引导扇区，其中包括一个非常小的引导记录和一个分区表。然后在引导扇区之后有一些保留空间，它跨越引导记录和硬盘驱动器上的第一个分区之间的空间，该分区通常位于下一个柱面边界上。GRUB2——以及可能的 GRUB1——使用此空间来存储其部分引导代码。

每个 EXT2 分区中的空间都分为柱面组，以便更精细地管理数据空间。根据我的经验，组大小通常约为 8MB。下图 1 显示了一个柱面组的基本结构。柱面中的数据分配单元是块，通常大小为 4K。

^{图 1：EXT 文件系统中柱面组的结构}

柱面组中的第一个块是一个超级块，其中包含定义其他文件系统结构并将其定位在物理磁盘上的元数据。分区中的一些附加组将具有备份超级块，但并非全部。损坏的超级块可以使用磁盘实用程序（如 dd）通过将备份超级块的内容复制到主超级块来替换。这种情况不常发生，但多年前，我曾经遇到过损坏的超级块，我能够使用其中一个备份超级块恢复其内容。幸运的是，我很有先见之明，使用了 dumpe2fs 命令来转储系统上分区描述符信息。

以下是 dumpe2fs 命令的部分输出。它显示了超级块中包含的元数据，以及关于文件系统中前两个柱面组中每一个组的数据。

# dumpe2fs /dev/sda1
Filesystem volume name:   boot 
Last mounted on:          /boot 
Filesystem UUID:          79fc5ed8-5bbc-4dfe-8359-b7b36be6eed3 
Filesystem magic number:  0xEF53 
Filesystem revision #:    1 (dynamic) 
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir nlink extra_isize 
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl 
Filesystem state:         clean 
Errors behavior:          Continue 
Filesystem OS type:       Linux 
Inode count:              122160 
Block count:              488192 
Reserved block count:     24409 
Free blocks:              376512 
Free inodes:              121690 
First block:              0 
Block size:               4096 
Fragment size:            4096 
Group descriptor size:    64 
Reserved GDT blocks:      238 
Blocks per group:         32768 
Fragments per group:      32768 
Inodes per group:         8144 
Inode blocks per group:   509 
Flex block group size:    16 
Filesystem created:       Tue Feb  7 09:33:34 2017 
Last mount time:          Sat Apr 29 21:42:01 2017 
Last write time:          Sat Apr 29 21:42:01 2017 
Mount count:              25 
Maximum mount count:      -1 
Last checked:             Tue Feb  7 09:33:34 2017 
Check interval:           0 (<none>) 
Lifetime writes:          594 MB 
Reserved blocks uid:      0 (user root) 
Reserved blocks gid:      0 (group root) 
First inode:              11 
Inode size:               256 
Required extra isize:     32 
Desired extra isize:      32 
Journal inode:            8 
Default directory hash:   half_md4 
Directory Hash Seed:      c780bac9-d4bf-4f35-b695-0fe35e8d2d60 
Journal backup:           inode blocks 
Journal features:         journal_64bit 
Journal size:             32M 
Journal length:           8192 
Journal sequence:         0x00000213 
Journal start:            0 


Group 0: (Blocks 0-32767) 
 Primary superblock at 0, Group descriptors at 1-1 
 Reserved GDT blocks at 2-239 
 Block bitmap at 240 (+240) 
 Inode bitmap at 255 (+255) 
 Inode table at 270-778 (+270) 
 24839 free blocks, 7676 free inodes, 16 directories 
 Free blocks: 7929-32767 
 Free inodes: 440, 470-8144 
Group 1: (Blocks 32768-65535) 
 Backup superblock at 32768, Group descriptors at 32769-32769 
 Reserved GDT blocks at 32770-33007 
 Block bitmap at 241 (bg #0 + 241) 
 Inode bitmap at 256 (bg #0 + 256)
 Inode table at 779-1287 (bg #0 + 779) 
 8668 free blocks, 8142 free inodes, 2 directories 
 Free blocks: 33008-33283, 33332-33791, 33974-33975, 34023-34092, 34094-34104, 34526-34687, 34706-34723, 34817-35374, 35421-35844, 35935-36355, 36357-36863, 38912-39935, 39940-40570, 42620-42623, 42655, 42674-42687, 42721-42751, 42798-42815, 42847, 42875-42879, 42918-42943, 42975, 43000-43007, 43519, 43559-44031, 44042-44543, 44545-45055, 45116-45567, 45601-45631, 45658-45663, 45689-45695, 45736-45759, 45802-45823, 45857-45887, 45919, 45950-45951, 45972-45983, 46014-46015, 46057-46079, 46112-46591, 46921-47103, 49152-49395, 50027-50355, 52237-52255, 52285-52287, 52323-52351, 52383, 52450-52479, 52518-52543, 52584-52607, 52652-52671, 52734-52735, 52743-53247 
 Free inodes: 8147-16288 
Group 2: (Blocks 65536-98303) 
 Block bitmap at 242 (bg #0 + 242) 
 Inode bitmap at 257 (bg #0 + 257) 
 Inode table at 1288-1796 (bg #0 + 1288) 
 6326 free blocks, 8144 free inodes, 0 directories 
 Free blocks: 67042-67583, 72201-72994, 80185-80349, 81191-81919, 90112-94207 
 Free inodes: 16289-24432 
Group 3: (Blocks 98304-131071)

<snip>

每个柱面组都有自己的 inode 位图，用于确定该组中哪些 inode 已使用，哪些是空闲的。inode 在每个组中都有自己的空间。每个 inode 包含关于一个文件的信息，包括属于该文件的数据块的位置。块位图跟踪文件系统中已使用和空闲的数据块。请注意，上面显示的输出中包含大量关于文件系统的数据。在非常大的文件系统上，组数据可能会运行到数百页的长度。组元数据包括组中所有空闲数据块的列表。

EXT 文件系统实现了数据分配策略，以确保最小的文件碎片。减少碎片提高了文件系统性能。这些策略在下面的 EXT4 部分中进行了描述。

EXT2 文件系统最大的问题，我在某些情况下遇到过，是崩溃后可能需要数小时才能恢复，因为 fsck（文件系统检查）程序需要很长时间才能找到并纠正文件系统中的任何不一致之处。有一次，在一台计算机上，在崩溃后重新启动时，完全恢复磁盘花了 28 个多小时——那时磁盘的大小还只有几百兆字节。

EXT3

EXT3 文件系统的唯一目标是克服 fsck 程序在完全恢复因文件更新操作期间发生的不当关机而损坏的磁盘结构所需的大量时间。EXT 文件系统的唯一补充是日志，它预先记录将对文件系统执行的更改。磁盘结构的其余部分与 EXT2 中的结构相同。

与以前的版本直接将数据写入磁盘的数据区域不同，EXT3 中的日志将文件数据及其元数据写入磁盘上的指定区域。一旦数据安全地存储在硬盘驱动器上，就可以将其合并或附加到目标文件，几乎不会丢失数据。当此数据提交到磁盘的数据区域时，日志会更新，以便在提交日志中的所有数据之前发生系统故障时，文件系统将保持一致状态。在下次启动时，将检查文件系统是否存在不一致之处，然后将日志中剩余的数据提交到磁盘的数据区域，以完成对目标文件的更新。

日志记录确实会降低数据写入性能，但是日志有三个选项可供选择，允许用户在性能与数据完整性和安全性之间进行选择。我个人更倾向于安全性，因为我的环境不需要大量的磁盘写入活动。

日志记录功能将故障后检查硬盘驱动器是否存在不一致之处所需的时间从数小时（甚至数天）缩短到最多几分钟。多年来，我遇到了许多导致系统崩溃的问题。细节可以再写一篇文章，但这里只需要说，大多数都是人为造成的，比如踢掉电源插头。幸运的是，EXT 日志文件系统已将启动恢复时间缩短到两三分钟。此外，自从我开始使用带有日志记录的 EXT3 以来，我从未遇到过数据丢失的问题。

EXT3 的日志记录功能可以关闭，然后它就像 EXT2 文件系统一样运行。日志本身仍然存在，但为空且未使用。只需使用 mount 命令重新挂载分区，并使用 type 参数指定 EXT2 即可。您可能可以从命令行执行此操作，具体取决于您正在使用的文件系统，但您可以更改 /etc/fstab 文件中的类型说明符，然后重新启动。我强烈建议不要将 EXT3 文件系统挂载为 EXT2，因为这会增加数据丢失和延长恢复时间的可能性。

可以使用以下命令将现有的 EXT2 文件系统升级到 EXT3，并添加日志。

tune2fs -j /dev/sda1

其中 /dev/sda1 是驱动器和分区标识符。请务必更改 /etc/fstab 中的文件类型说明符，并重新挂载分区或重新启动系统以使更改生效。

EXT4

EXT4 文件系统主要提高了性能、可靠性和容量。为了提高可靠性，添加了元数据和日志校验和。为了满足各种关键任务需求，文件系统时间戳得到了改进，增加了低至纳秒的间隔。在时间戳字段中添加两个高位位会将2038 年问题推迟到 2446 年——至少对于 EXT4 文件系统而言是这样。

在 EXT4 中，数据分配从固定块更改为区段。区段由其在硬盘驱动器上的起始和结束位置描述。这使得在单个 inode 指针条目中描述非常长的、物理上连续的文件成为可能，这可以显着减少描述较大文件中所有数据位置所需的指针数量。EXT4 中还实现了其他分配策略，以进一步减少碎片。

EXT4 通过将新创建的文件分散在磁盘上，使其不会像许多早期 PC 文件系统那样聚集在磁盘开头的某个位置，从而减少碎片。文件分配算法尝试将文件尽可能均匀地分布在柱面组之间，并且在碎片是必要的情况下，使不连续的文件区段尽可能靠近同一文件中的其他区段，以尽可能减少磁头寻道和旋转延迟。当创建新文件或扩展现有文件时，还使用其他策略来预先分配额外的磁盘空间。这有助于确保扩展文件不会自动导致其碎片化。新文件永远不会紧跟在现有文件之后分配，这也防止了现有文件的碎片化。

除了磁盘上数据的实际位置之外，EXT4 还使用功能策略，例如延迟分配，以允许文件系统在为其分配空间之前收集所有正在写入磁盘的数据。这可以提高数据空间连续的可能性。

较旧的 EXT 文件系统，如 EXT2 和 EXT3，可以挂载为 EXT4 以获得一些小的性能提升。不幸的是，这需要关闭 EXT4 的一些重要新功能，因此我不建议这样做。

自 Fedora 14 以来，EXT4 一直是 Fedora 的默认文件系统。可以使用 Fedora 文档中描述的步骤将 EXT3 文件系统升级到 EXT4，但是由于残留的 EXT3 元数据结构，其性能仍然会受到影响。从 EXT3 升级到 EXT4 的最佳方法是备份目标文件系统分区上的所有数据，使用 mkfs 命令将空的 EXT4 文件系统写入分区，然后从备份中恢复所有数据。

Inode

如前所述，inode 是 EXT 文件系统中元数据的关键组件。图 2 显示了 inode 与存储在硬盘驱动器上的数据之间的关系。此图是单个文件的目录和 inode，在这种情况下，该文件可能高度碎片化。EXT 文件系统积极工作以减少碎片，因此您不太可能看到具有如此多间接数据块或区段的文件。事实上，正如您将在下面看到的，EXT 文件系统中的碎片非常低，因此大多数 inode 将仅使用一个或两个直接数据指针，而不会使用任何间接指针。

^{图 2：inode 存储关于每个文件的信息，并使 EXT 文件系统能够定位属于它的所有数据。}

inode 不包含文件名。通过目录条目访问文件，目录条目本身就是文件名，并且包含指向 inode 的指针。该指针的值是 inode 编号。文件系统中的每个 inode 都有一个唯一的 ID 编号，但同一计算机（甚至同一硬盘驱动器）上其他文件系统中的 inode 可以具有相同的 inode 编号。这对链接有影响，而此讨论超出了本文的范围。

inode 包含关于文件的元数据，包括其类型和权限以及其大小。inode 还包含 15 个指针的空间，这些指针描述了柱面组数据部分中数据块或区段的位置和长度。十二个指针提供对数据区段的直接访问，并且应该足以处理大多数文件。但是，对于具有大量碎片的文件，有必要具有一些额外的功能，即间接节点的形式。从技术上讲，这些实际上不是 inode，因此我在这里为了方便起见使用了术语“节点”。

间接节点是文件系统中的一个普通数据块，仅用于描述数据，而不用于存储元数据，因此可以支持超过 15 个条目。例如，4K 的块大小可以支持 512 个 4 字节的间接节点，从而允许单个文件有 12（直接）+ 512（间接）= 524 个区段。还支持双重和三重间接节点，但我们大多数人不太可能遇到需要如此多区段的文件。

数据碎片

对于许多较旧的 PC 文件系统，例如 FAT（及其所有变体）和 NTFS，碎片一直是导致磁盘性能下降的重大问题。磁盘碎片整理本身已成为一个行业，不同的磁盘碎片整理软件品牌从非常有效到仅略微有效不等。

Linux 的扩展文件系统使用数据分配策略，这些策略有助于最大限度地减少硬盘驱动器上文件的碎片，并在碎片确实发生时减少碎片的影响。您可以使用 EXT 文件系统上的 fsck 命令来检查文件系统的总碎片。以下示例检查了我的主工作站的主目录，该目录的碎片率仅为 1.5%。请务必使用 -n 参数，因为它会阻止 fsck 对扫描的文件系统执行任何操作。

fsck -fn /dev/mapper/vg_01-home

我曾经进行过一些理论计算，以确定磁盘碎片整理是否可能导致任何明显的性能提升。虽然我做了一些假设，但我使用磁盘性能数据来自一个新的 300GB Western Digital 硬盘驱动器，其磁道到磁道寻道时间为 2.0ms。此示例中的文件数是我在进行计算当天文件系统中存在的实际文件数。我确实假设相当大一部分碎片文件（20%）每天都会被访问。

文件总数	271,794
碎片百分比	5.00%
不连续性	13,590

每天访问的碎片文件百分比	20%（假设）
额外寻道次数	2,718
平均寻道时间	10.90 毫秒
每天的总额外寻道时间	29.63 秒
	0.49 分钟

磁道到磁道寻道时间	2.00 毫秒
每天的总额外寻道时间	5.44 秒
	0.091 分钟

^{表 1：碎片对磁盘性能的理论影响}

我已经对每天的总额外寻道时间进行了两次计算，一次是基于磁道到磁道寻道时间，这对于大多数文件来说是更可能的情况，因为 EXT 文件分配策略，另一次是针对平均寻道时间，我假设这会构成相当糟糕的情况。

正如您从表 1 中看到的那样，碎片对现代 EXT 文件系统的影响，即使是性能适中的硬盘驱动器，对于绝大多数应用程序来说也是微乎其微的，可以忽略不计。您可以将您环境中的数字插入您自己的类似电子表格中，以查看您可能会期望的性能影响。这种类型的计算最有可能无法代表实际性能，但它可以提供对碎片及其对系统的理论影响的一些了解。

我的大多数分区都只有大约 1.5% 或 1.6% 的碎片；我确实有一个分区有 3.3% 的碎片，但这是一个 128GB 的大文件系统，只有不到 100 个非常大的 ISO 映像文件；多年来，我不得不多次扩展分区，因为它变得太满了。

但这并不是说某些应用程序环境不需要更高程度的保证，甚至更少的碎片。EXT 文件系统可以通过知识渊博的管理员小心地进行调整，管理员可以调整参数以补偿特定的工作负载类型。这可以在创建文件系统时完成，也可以稍后使用 tune2fs 命令完成。应测试、仔细记录和分析每次调整更改的结果，以确保目标环境的最佳性能。在最坏的情况下，如果性能无法提高到所需水平，则可以使用其他文件系统类型，这些类型可能更适合特定的工作负载。请记住，在单个主机系统上混合使用文件系统类型以匹配每个文件系统上的负载是很常见的。

由于大多数 EXT 文件系统上的碎片量很少，因此没有必要进行碎片整理。无论如何，EXT 文件系统没有安全的碎片整理工具。有一些工具允许您检查单个文件的碎片或文件系统中剩余可用空间的碎片。有一个工具 e4defrag，它将在剩余可用空间允许的范围内对文件、目录或文件系统进行碎片整理。顾名思义，它仅适用于 EXT4 文件系统中的文件，并且确实有一些限制。

如果必须在 EXT 文件系统上执行完整的碎片整理，则只有一种方法可以可靠地工作。您必须将要进行碎片整理的文件系统中的所有文件移动到另一个位置，确保在安全复制到另一个位置后将其删除。如果可能，您可以增加文件系统的大小，以帮助减少未来的碎片。然后将文件复制回目标文件系统。即使这样也不能保证所有文件都将完全碎片整理。

结论

EXT 文件系统已成为许多 Linux 发行版 20 多年的默认文件系统。它们提供稳定性、高容量、可靠性和性能，同时只需最少的维护。我尝试过其他文件系统，但总是回到 EXT。我使用 Linux 的每个地方都使用了 EXT 文件系统，并发现它们适用于其上使用的所有主流负载。毫无疑问，除非有令人信服的理由使用其他文件系统，否则 EXT4 文件系统应被用于大多数 Linux 系统。

标签

Linux