文件系统(八)—文件系统的前世今生

原文：An Introduction to Linux’s EXT4 Filesystem

链接： https://opensource.com/article/17/5/introduction-ext4-filesystem

本文的目的是仔细阅读EXT4的历史记录，功能和最佳使用，并了解其与Ext文件系统的先前迭代的不同之处。

在先前关于Linux文件系统的文章中，我写了一份说明书去介绍Linux文件系统，里面有一些高级的概念，比如说，一切都是文件。我很想去深入地讨论更多EXT文件系统的特性的信息。所以，首先让我们来回答这个问题：什么是文件系统？一个文件系统应该遵循以下特点：

Data storage: 任何文件系统都是用来结构化存储数据和检索数据
Namespace: 提供一套命名和组织的方法，可为命名和结构数据提供规则
Security model: 一种访问控制的策略
API: 提供系统函数调用以操纵文件系统对象，例如目录和文件。
Implementation: 一个实现以上功能的软件
1. EXT 文件系统历史
虽然ext文件系统是为linux编写，但ext文件系统起源于minix操作系统，而minix文件系统早在1987年首次发布，比Linux系统还早5年发布。如果我们了解EXT文件系统家族从其minix开始的历史和技术演变过程，就会更容易的理解EXT4文件系统。

1.1 Minix
当编写原始的Linux内核的时候，Linus Torvalds需要一个文件系统，但是他又不想编写一个文件系统。因此，他简单实用了Minix文件系统，这个是Andrew S. Tanenbaum开发的，而且是Tanenbaum 的Minix操作系统的一部分。由于Minix是为教育目的而编写的类Unix的操作系统，其代码是免费的，并获得了许可授权给Torvalds，以允许Linux将其纳入第一个版本的Linux系统中。

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

引导扇区（boot sector）安装于硬盘的第一个扇区。引导块（boot block）包含一个非常小的引导记录和一个分区表。
每一个分区中的第一个块是超级块（superblock），它包含了定义其他文件系统结构的元数据，并将它们定位在分配给分区的物理磁盘上。
节点位图块（inode bitmap block），它确定了哪个节点在使用以及哪个节点是空闲的。
节点（inodes），它们在磁盘上有它们自己的空间。每个节点包含了一个文件的信息，包括数据块的位置，即文件所属的区域。
区域位图（zone bitmap）跟踪记录数据区域的使用和释放。
数据区域（data zone），数据实际上存储的位置。
对于位图的两个类型来说，一个位代表一个特定的数据区域或者inode位图。如果为0，则代表该区域可以正常使用，但是如果为1，则代表该数据区或inode正在使用中。

什么是inode? 它是索引节点（index-node）的缩写，一个节点是在磁盘上的一个256字节的块，并存储文件相关的数据。这些数据包括

文件的大小
文件的用户和所属组的用户ID
文件模式（即访问权限）
三个时间戳具体说明了时间，包括：文件最后访问时间，最后修改时间，以及节点中的数据最后修改时间。
节点Inode也包含了：指向硬盘上文件数据所在的位置。在Minix和EXT1-3文件系统中，它是一个数据区域和块的列表。Minix文件系统节点支持9个数据块，7个直接指针和2个间接指针。如果你想了解的更多，这有一个很好的PDF详细描述了Minix文件系统结构，以及在Wikipedia上对节点指针结构的快速概述。
1.2 EXT
原始的Ext文件系统（扩展）由Rémy卡编写，并于1992年与Linux发布，以克服Minix文件系统的的一些大小限制。主要的结构更改是基于Unix文件系统（UFS）的文件系统的元数据，该文件系统也称为伯克利快速文件系统（FFS）。我发现几乎没有关于EXT文件系统的发布信息，可以验证，这显然是因为它存在重大问题，并且很快被EXT2文件系统取代。

1.3 EXT2
EXT2文件系统非常成功。它在Linux发行版中使用了很多年，并且它是我在1997年开始使用Red Hat Linux 5.0时遇到的第一个文件系统。ExT2文件系统基本上具有与Ext Filesysty相同的元数据结构，但是Ext2更具前瞻性，元数据结构之间保留下了许多磁盘空间，以供将来使用。

像Minix一样，EXT2在安装硬盘驱动器的第一个扇区中具有引导扇区，其中包括很小的引导记录和一个分区表。然后在引导扇区之后有一些预留的空间，该空间跨越了引导记录和通常位于下一个气缸边界上的硬盘驱动器上的第一个分区之间的空间。GRUB2（可能是GRUB1），可以为其一部分引导代码提供此空间。

每个EXT2分区中的空间都分为圆柱体组，从而可以对数据空间进行更详细的管理。根据我的经验，小组的规模通常约为8MB。下图1显示了圆柱体的基本结构。气缸中的数据分配单元是块，通常为4K。

柱面组中的第一个块是一个超级块，它包含定义其他文件系统结构并将其定位在物理磁盘上的元数据。分区中的一些附加组将具有备份超级块，但不是全部。损坏的超级块可以使用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>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
每个柱面组都有自己的inode位图，该位图用于确定使用哪些inode，以及该组中哪些是空闲的。inode在每个组中都有自己的空间。每个inode都包含有关一个文件的信息，包括属于该文件的数据块的位置。块位图跟踪文件系统中使用和释放的数据块。注意，上面显示的输出中有大量关于文件系统的数据。在很大的文件系统中，组数据可以长达数百页。组元数据包括组中所有空闲数据块的列表。

EXT文件系统实现了保证文件碎片最小化的数据分配策略。减少磁盘碎片化可改善文件系统的性能。这些策略将在下文的EXT4部分中进行介绍。

在某些情况下，我曾遇到的EXT2文件系统的最大问题是，在崩溃后可能需要几个小时才能恢复，因为fsck（file system check）程序需要很长时间才能找到并纠正文件系统中的任何不一致。它曾在我的一台计算机上花费了28个小时的时间，以实现在发生崩溃到重新启动时完全恢复磁盘 -并且这是在磁盘大小为数百兆字节下测试的结果。

1.3 EXT3
EXT3文件系统的唯一目标是克服fsck程序需要大量时间来完全恢复因文件更新操作期间发生的不正确关闭而损坏的磁盘结构的问题。EXT文件系统的唯一增加是journal，它预先记录了将对文件系统执行的改动。磁盘结构的其余部分和EXT2中是相同的。

EXT3中的journal并不是直接将数据写入磁盘的数据区域，而是将文件数据及其元数据写入到磁盘上的指定区域。一旦数据安全地存储在硬盘上，它就可以合并到目标文件或附加到目标文件中，而这几乎不会丢失数据。由于该数据被提交到磁盘的数据区域，因此需更新journal以便在发生系统故障时文件系统保持一致状态，然后该journal中的所有数据都被提交。在下次启动时，将检查文件系统是否存在不一致性，然后将journal中剩余的数据提交到磁盘的数据区域以完成对目标文件的更新。

日志化确实会降低数据写入性能，但journal提供了三种选项可供用户在性能，数据完整性和安全性之间进行选择。我的个人偏好是安全性，因为我的环境不需要繁重的磁盘写入操作。

journal方式：
所有数据（data+metadata）在被写入文件系统前，都要先写入到journal区域，可靠性很好，但是性能却最差。
ordered方式：
这种方式不用记录data，但是需要在data写入文件系统之后，把metadata写入到journal区域，相比前一种提高了性能，稍微降低的可靠性。
writeback：
这种方式不用记录data，只需要把metadata写入到journal区域，但不保证data已经写入文件系统，所以它的可靠性最差。
日志函数最多可以减少在检查硬盘驱动发现不一致性所需的时间：从几小时（甚至几天）到几分钟不等。多年来，我遇到了很多导致系统崩溃的问题。个中细节我会另起一篇文章，但足以证实大多数是自我原因造成的，就像踢掉电源插头一样。幸运的是，EXT日志化文件系统已将启动恢复时间缩短到两三分钟。另外，自从我开始使用带日志功能的EXT3以来，我从来没有遇到丢失数据的问题了。

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

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

tune2fs -j /dev/sda1
1
其中/dev/sda1是驱动器和分区标识符。确保在/etc/fstab中更改文件类型说明符，并重新启动分区或重新启动系统以使更改生效。

1.4 EXT4
EXT4文件系统主要改善了性能，可靠性和容量。为了提升可靠性，添加了元数据和日志校验和。为了满足各种各样的关键任务的需求，文件系统时间戳将时间间隔精确到了纳秒。时间戳字段的两个高位bit将2038年问题延续到了2446年——至少为EXT4文件系统延续了。

在EXT4中，数据分配从固定块变成了扩展块。一个扩展块通过它在硬盘上的起始和结束位置来描述。这使得在一个单一节点指针条目中描述非常长的物理连续文件成为可能，它可以显著减少大文件中的描述所有数据的位置的所需指针的数量。为了进一步减少碎片化，其他分配策略已经在EXT4中实现。

EXT4通过在磁盘上分散新创建的文件来减少碎片化，因此他们不会像早期的PC文件系统，聚集在磁盘的起始位置。文件分配算法尝试尽量将文件均匀的覆盖到柱面组，而且当不得不产生碎片时，尽可能地将间断文件范围靠近同一个文件的其他碎片，来尽可能压缩磁头寻找和旋转等待时间。

当一个新文件创建的时候或者当一个已有文件扩大的时候，附加策略用于预分配额外磁盘空间。它有助于保证扩大文件不会导致它直接变为碎片。新文件不会直接分配在已存在文件的后面，这也阻止了已存在文件的碎片化。

除了数据在磁盘的具体位置，EXT4使用一些功能策略，例如延迟分配，允许文件系统在分配空间之前先收集到要写到磁盘的所有数据。这可以提高数据空间连续的概率。

之前的EXT文件系统，例如EXT2和EXT3，可以挂载EXT4，来提升一些次要性能。不幸的是，它要求关掉一些EXT4的重要的新特性，因此我不建议这种做法。

从Fedora 14开始，EXT4已经是Fedora的默认文件系统。使用在Fedroa文档描述的过程，一个EXT3文件系统可以升级到EXT4，然而由于剩余的EXT3元数据结构，它的性能仍然会受到影响。从EXT3升级到EXT4最好的方法是备份所有的目标文件系统分区的数据，使用mkfs命令将一个空的EXT4文件系统写到分区，然后从备份恢复所有数据。

1.5 Inode
在之前描述过，节点是一个EXT文件系统的元数据的关键组成部分。图2展示了节点和存储在硬盘上的数据之间的关系。这个示意图是目录和单一文件的节点，在这种情况下，可能是高度碎片化文件的节点。EXT文件系统为减少碎片化而积极努力，因此你不会看到有很多间接数据块或者数据区的文件。事实上，就像你将在下面看到的，碎片化在EXT文件系统中非常少见，因此大多节点会只用一个或者两个直接数据指针而且不使用间接指针。

节点不包含文件的名称。通过目录项（directory entry）来访问文件，该目录本身就是文件的名称，并包含指向inode节点的指针。每个文件系统中的节点都有一个唯一的ID号，但是在同一个电脑（甚至同一个硬盘）的其他文件系统中的节点可以有相同的节点号。这会对硬连接产生一些后果，这方面内容超出了本文的范围。

节点包含了文件的元数据，包括它的类型和权限以及它的大小。节点也包含了15个指针的空间，来描述柱面组中数据部分中的数据块或数据区的位置和长度。12个指针提供了数据区的直接访问，而且对处理大部分文件都是足够的。然而，对于有大量碎片的文件，它可能必须需要一些额外的空间，以间接节点的形式描述。从技术上来讲，它们不是真正的节点，因此为了方便我使用短语“间接节点（node）”。

间接节点是文件系统中一个常规的数据块，只用于描述数据而且不用存储元数据，因此可以支持超过15个指针。例如，一个大小为4K的块可以支持512个4字节间接节点，允许一个单一文件包含12（直接）+512（间接）=524个区。同样也支持双重或三重间接节点，但是我们一般不太可能遇到需要这么多区的文件。

1.6 数据碎片化(data fragmentation)
对于许多较旧的PC文件系统，例如FAT（及其所有变体）和NTF，碎片化是一个重要的问题，导致磁盘性能降低。碎片部门本身就是一个行业，具有不同品牌的碎片化软件，从非常有效到略有差异。

Linux的扩展文件系统使用数据分配策略，有助于最大程度地减少文件上的文件的碎片化，并在发生时减少碎片的影响。您可以在Ext文件系统上使用FSCK命令来检查来整个文件系统的碎片。下面的示例检查了我的主要工作站的主目录，该目录仅为1.5％。请确保使用-n参数，因为它可以防止FSCK对扫描文件系统采取任何操作。

fsck -fn /dev/mapper/vg_01-home
1
我曾经进行过一些理论上的计算，以确定磁盘碎片整理是否会导致性能显着提高。虽然我确实做了一些假定，但我使用的磁盘性能数据来自新的300GB，Western Digital硬盘，具有2.0ms的磁轨间寻址时间。本例中的文件数量是我在计算当天存在于该文件系统中的实际数量。我确实假定每天都会触发相当多的碎片文件（20％）。

我已经做了两次测算，每天总的附加寻址时间，一次是基于磁轨间寻址时间，这是由于EXT文件分配策略而导致大多数文件更可能出现的情况，另一种是平均寻址时间，我假定这会触发相当于最坏的情形。

从表1可以看出，对于具有相当性能的硬盘驱动器的现代EXT文件系统来说，碎片化影响最小；对绝大多数应用程序来说可以忽略不计。你可以将实际环境中的数据插入到你自己的类似电子表格中，以得到你对性能影响的预期。这种计算方式很可能不会代表实际性能，但它可以提供对碎片话及其对系统的理论上的影响的一些洞察力。

我的大部分分区大约1.5％或1.6％碎片化;我确实有一个3.3％碎片化的分区，但这是一个大128GB的文件系统，拥有少于100个非常大的ISO映像文件;多年来，我不得不多次扩展此分区，因为它太满了。

这并不是说某些应用程序环境不需要更少的碎片文件的保证。EXT文件系统可以由知识渊博的管理员进行调整，他们可以调整参数以补偿特定的工作负载类型。这可以在文件系统被创建时或之后使用tune2fs命令来完成。应对每次调优改动的结果进行测试，细致地记录并进行分析，以确保对目标环境达到最佳性能。在最差的情况下，如果性能无法提升到所需的水平，则可能有更适合特定工作负载的其他文件系统类型。请记住，在单个主机系统上混用文件系统类型以匹配每个文件系统上的负载是很常见的。

由于在大多数EXT文件系统中碎片数量很少，因此不需要进行碎片整理。无论如何，EXT文件系统都没有安全的碎片整理工具。目前有几个工具可以让你检查单个文件的碎片状况或文件系统中剩余空闲空间的碎片化状态。有一个工具，e4defrag，它将在可用空间允许的前提下对文件、目录或文件系统进行尽可能地碎片化整理。顾名思义，它只适用于EXT4文件系统中的文件，并且存在一些局限性。

如果有必要对EXT文件系统执行完全的碎片整理，则仅有一种方法可以可靠地工作。你必须移动文件系统中的所有文件以进行碎片整理，以确保在将文件安全复制到其他位置后将其删除。如果可能的话，你可以增加文件系统的大小来辅助减少将来的碎片产生。然后将文件复制回目标文件系统。即使这样做并不能保证所有的文件都会被完全去碎片化。

2 总结
ext文件系统是一个老牌的Linux的文件系统，是Linux的第一个文件系统。虽然业界将Ext文件系统看成是一个过度用的文件系统，但是现在的Ext4依然有很强的生命力。从ext2-ext3-ext4，文件系统的磁盘布局没有发生太大的变化，从ext2到ext3，主要是增强了可用性、数据完整性、速度、易于迁移等功能；ext3到ext4就不仅仅是功能增强，它修改了某一些重要的数据结构，并且在对大文件的支持上做了更多的优化改进。

对于布局，ext文件系统从ext2-ext4磁盘布局并没有太大的改动，如下图

其主要改动如下：

Block Group: ext文件系统将文件系统分块组管理，在写文件时，尽可能保证文件集中在块组内，减少读取时磁盘旋转的开销。块组的结构如上图，这里要注意，块组0的结构和其他组有点区别，块组0开始位置多了一个固定1024byte用于安装x86引导扇区以及其他信息。

Meta Block Group(元块组): 改进GDT，上边描述了ext2中GDT的局限，在ext3中引入了Meta Block Group，其固定用一个块来存放GDT，用于记录连续的组组成的一个元块组，GDT不在跟随super block一起备份，而是在自己元块组内备份，分别存放在元块组的1,2号组和最后一个组上。元块组的大小为一个块能存放的组描述数数目

Flexible Block Groups： 我们知道，机械硬盘每次读取块前要先寻道，相对读取数据，寻道开销是非常高的，而block bitmap、i-node table、i-node table这些数据需要频繁加载，它们分散在各个组上存放就会导致频繁的寻道。为了减少加载block bitmap、i-node table、i-node table时的寻道开销和大文件的连续块分配，ext4引入了Flexible Block Groups，它将一定数量的物理块组连起来组成一个逻辑块组，block bitmap、i-node table、i-node table按顺序存储在逻辑块组的第一个块组上

简单的示意图，注意该图只是一个简单示意图，一个方块并不代表一个块，block bitmip、i-node bitmap依然是一个组一个块，i-node table依顺序占用多个块

Extent 树:

ext2/3时，i-node中指向文件数据块采用直接/间接块地址，如下图，0-11是直接地址，之后的块分为3种，第一种是一级间接地址，第二种是二级，第三种三级，随着间接级数变大，指向的数据块越多，但是这种表示方法有一个缺点，那就是如果数据块连续，依然会每个数据块都存储一个地址，很浪费空间

ext4采用Extent树优化了这种情况，它的核心原理是连续块只存储起始块和连续的块数，每个节点都是以ext4_extent_header(12byte)结构开始，然后如果是内节点，则后边是ext4_extent_idx的项其大小为12byte；如果是叶子节点，则后边是ext4_extent，其大小也是12byte。

目录项

线性(传统)目录，示意图如下，ext4默认是ext4_dir_entry_2，ext4_dir_entry_2和ext4_dir_entry的区别主要是因为文件名不超过255，所以不需要16位存储文件名，因此抽出8位用来存储文件类型，inode 2是系统保留的inode号代表根目录，该图是简单的根目录下的文件目录项示意图，可以看到在块内查找一个文件几乎要遍历目录项数组对比文件名

Hash树目录，由于传统目录查找文件几乎是遍历查找，出于性能的考虑，ext3引入了文件名hash值的B树来提升查找文件的速度。其结构如下图，树的root通常保存在文件的第一个数据块中，这里有一个地方要**注意**dx_entry结构中的block号是文件内部的块号，代表是文件的第几个数据块，并非文件系统的块号。
1

jbd2日志

jdb2流程简单示意图，写文件时，先写到磁盘缓冲区，然后写到journal（是一个文件系统保留区域，inode为8，大小默认128MB），因为是顺序写，速度很快。当写入完成时，写入一个提交记录，然后刷新磁盘缓冲区。之后文件系统会将journal的提交记录在擦除前写入最终的位置，这里的写就可能会比较慢，因为数据可能需要写到不同块，需要多个寻道开销

jdb2日志模式

ordered(默认级别)：只将文件系统元数据写入journal，当系统崩溃时，不能保证任何一致性状态
journal：所有数据和元数据都会写入到journal，该模式比较慢，但是很安全
writeback：在元数据通过journal写入到磁盘最终位置前，脏数据不能刷新到磁盘
崩溃恢复：当系统崩溃重启时，文件系统利用journal的最近的提交记录重放写过程来恢复数据，journal详细的数据结构参考jdb2

20多年来，EXT文件系统一直是许多Linux发行版的默认文件系统。它们需要少量的维护就能提供稳定性、高容量、可靠性和性能。我尝试过其他文件系统，但总是回到EXT。毫无疑问，EXT4文件系统应该用于大多数Linux系统，除非有令人信服的理由去使用另一个文件系统。

3. 参考文档
https://houwanfei.github.io/2020/07/04/操作系统-番外-老牌Linux文件系统Ext/

https://opensource.com/article/17/5/introduction-ext4-filesystem
————————————————
版权声明：本文为CSDN博主「奇小葩」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u012489236/article/details/124901169