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

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

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

EXT文件系统历史记录

尽管EXT文件系统是为Linux编写的，但其根源是Minix操作系统和Mi​​nix文件系统，它们早于Linux大约五年，于1987年首次发布。了解EXT4文件系统要容易得多，如果我们回顾一下历史和技术从Minix根源扩展EXT文件系统系列。

极小

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

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

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

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

什么是inode ？ 索引节点的缩写，索引节点是磁盘上的256字节块，用于存储有关文件的数据。 这包括文件的大小； 文件的用户和组所有者的用户标识； 文件模式（即访问权限）； 和三个时间戳记，它们指定以下时间和日期：上次访问文件，上次修改文件和上一次修改inode中的数据。

索引节点还包含指向硬盘驱动器上文件数据位置的数据。 在Minix和EXT1-3文件系统中，这是数据区或块的列表。 Minix文件系统inode支持九个数据块，七个直接块和两个间接块。 如果您想了解更多信息，可以在Wikipedia上找到一份出色的PDF，其中包含Minix文件系统结构的详细说明和inode指针结构的快速概述。

外部

最初的EXT文件系统 （扩展）由RémyCard编写，并于1992年随Linux发行，以克服Minix文件系统的某些大小限制。 主要的结构更改是基于Unix文件系统（UFS）（也称为Berkeley快速文件系统（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都有自己的空间。 每个索引节点包含有关一个文件的信息，包括属于该文件的数据块的位置。 块位图跟踪文件系统中已使用和可用的数据块。 注意，在上面显示的输出中，有很多关于文件系统的数据。 在非常大的文件系统上，组数据的长度可以达到数百页。 组元数据包括该组中所有空闲数据块的列表。

EXT文件系统实施了数据分配策略，以确保文件碎片最少。 减少碎片可以提高文件系统性能。 下文在EXT4的部分中介绍了这些策略。

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

EXT3

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

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

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

日志功能最多可将故障后检查硬盘驱动器不一致的时间从数小时（甚至数天）减少到仅几分钟。 这些年来，我遇到了很多使系统崩溃的问题。 这些细节可能会充斥另一篇文章，但足以说明大多数是自安装的，例如拔出电源插头。 幸运的是，EXT日志文件系统已将启动恢复时间减少到两到三分钟。 另外，自从我开始将EXT3与日记一起使用以来，我从未遇到过数据丢失的问题。

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

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

tune2fs -j / dev / sda1 

/ dev / sda1是驱动器和分区标识符。 确保更改/ etc / fstab中的文件类型说明符，然后重新挂载分区或重新引导系统，以使更改生效。

EXT4

EXT4文件系统主要提高了性能，可靠性和容量。 为了提高可靠性，添加了元数据和日记校验和。 为了满足各种关键任务要求，文件系统时间戳得到了改进，增加了几秒钟的间隔。 在timestamp字段中添加两个高阶位至少可以将EXT4文件系统的2038年问题推迟到2446年。

在EXT4中，数据分配从固定块更改为扩展区。 范围通过其在硬盘驱动器上的开始和结束位置来描述。 这样就可以在单个inode指针条目中描述很长的，物理上连续的文件，这可以大大减少描述较大文件中所有数据位置所需的指针数量。 EXT4中已实施了其他分配策略，以进一步减少碎片。

EXT4通过在磁盘上散布新创建的文件来减少碎片，从而使它们不会像许多早期的PC文件系统那样在磁盘的开头集中在一个位置。 文件分配算法试图在圆柱组之间尽可能均匀地分布文件，并且在需要分段时，要使不连续的文件范围尽可能与同一文件中的其他文件区保持尽可能近的距离，以最大程度地减少磁头查找和旋转延迟尽可能。 创建新文件或扩展现有文件时，可以使用其他策略来预分配额外的磁盘空间。 这有助于确保扩展文件不会自动导致其碎片化。 新文件绝不会在现有文件之后立即分配，这也可以防止现有文件碎片化。

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

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

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

索引节点

如前所述，索引节点是EXT文件系统中元数据的关键组成部分。 图2显示了索引节点和存储在硬盘驱动器上的数据之间的关系。 此图是单个文件的目录和索引节点，在这种情况下，该文件可能会高度分散。 EXT文件系统积极地工作以减少碎片，因此，您几乎不可能看到具有如此众多间接数据块或扩展数据块的文件。 实际上，正如您将在下面看到的那样，EXT文件系统中的碎片非常少，因此大多数inode只会使用一个或两个直接数据指针，而不会使用任何间接指针。

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

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

索引节点包含有关文件的元数据，包括其类型和权限以及其大小。 索引节点还包含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 

我曾经进行过一些理论计算，以确定磁盘碎片整理是否可以导致任何明显的性能提升。 尽管我确实做了一些假设，但我使用的磁盘性能数据来自具有300ms轨道间寻道时间的新型300GB Western Digital硬盘。 此示例中的文件数是我进行计算当天文件系统中存在的实际数。 我确实假设每天会碰到相当多的碎片文件（20％）。

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

我已经对每天的总额外搜寻时间做了两次计算，一次是基于轨道到轨道的搜寻时间，这是大多数文件由于EXT文件分配策略而发生的情况，而另一次是平均搜寻时间，我认为这会造成最坏的情况。

从表1中可以看出，对于绝大多数应用程序而言，碎片对现代EXT文件系统的影响是很小的，甚至可以忽略不计。 您可以将环境中的数字插入到自己的类似电子表格中，以查看对性能产生影响的预期结果。 这种类型的计算很可能无法代表实际性能，但可以提供一些有关碎片化及其对系统的理论影响的见解。

我的大多数分区都是大约1.5％或1.6％的碎片。 我确实有一个碎片是3.3％，但是那是一个128GB的大型文件系统，只有不到100个非常大的ISO映像文件。 这些年来，由于分区太满，我不得不多次扩展分区。

这并不是说某些应用程序环境不需要更大的保证就可以减少碎片。 经验丰富的管理员可以谨慎地调整EXT文件系统，管理员可以调整参数以补偿特定的工作负载类型。 这可以在创建文件系统时执行，也可以稍后使用tune2fs命令来完成。 应对每个调整更改的结果进行测试，精心记录和分析，以确保针对目标环境的最佳性能。 在最坏的情况下，如果无法将性能提高到所需的水平，则可以使用其他文件系统类型，这些类型可能更适合于特定的工作负载。 请记住，通常在单个主机系统上混合文件系统类型以匹配每个文件系统上的负载。

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

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

结论

二十多年来，EXT文件系统已成为许多Linux发行版的默认文件系统。 它们提供稳定性，高容量，可靠性和性能，同时只需最少的维护。 我尝试了其他文件系统，但始终返回到EXT。 我在Linux上工作过的每个地方都使用EXT文件系统，并发现它们适用于在它们上使用的所有主流负载。 毫无疑问，除非有充分的理由使用另一个文件系统，否则EXT4文件系统应该用于大多数Linux系统。

翻译自: https://opensource.com/article/17/5/introduction-ext4-filesystem