EXT2/EXT3文件系统

ゝ一世哀愁。 2022-04-08 14:40 283阅读 0赞

### 文件系统概念引入 ###

文件系统是一种存储和组织计算机数据的方法，它使得对计算机的访问和查找变得容易，文件系统使用**文件**和**树形目录**的抽象逻辑概念代替了硬盘和光盘等物理设备使用数据块的概念，用户使用文件系统来保存数据不必关心数据实际保存在硬盘（或者光盘）的地址为多少的数据块上，只需要记住这个文件所属目录和文件名。在写入新数据之前，用户不必关心硬盘上的那个地址有没有被使用，硬盘上的存储空间管理（分配和释放）功能由文件系统自动完成，用户只需要记住数据被写到了哪个文件中。

我们都知道磁盘分区后还要进行格式化，之后操作系统才能够使用这个分区。这是因为每种操作系统所设置的文件属性/权限不同，为了存放这些数据所需要的空间，因此就要对分区进行格式化，以便成为操作系统能够利用的文件系统格式。

文件数据除了文件的实际内容外，还含有文件权限（RWX）与文件属性（所有者、群组、时间参数等）。文件系统通常会把这两部分数据放到不同的块中，权限与属性放置到inode中，至于实际数据则放置到data-block中。另外，还有一个Superblock会记录文件的整体信息，包括inode与block的总量、使用量’剩余量等。

每个inode和block都有编号，这三个数据的意义简要的说明如下：

*  superblock：记录文件的整体信息，包括inode/block的总量、使用量、剩余量，以及文件系统的格式与相关信息等；
 *  inode：记录文件属性，一个文件占用一个inode，同时记录此文件的数据所在的blick号码；
 *  block：实际记录文件的内容，若文件太大，会占用多个block。

由于inode和block都有自己的编号，而每个文件都会占有一个inode，inode内则含有文件数据放置的block号码。所以，如果能找到文件的inode，那么自然就会知道数据存放到哪些block了，也可以对数据进行读取。

**inode/block数据访问示意图：**  
![在这里插入图片描述][SouthEast]  
如图所示，文件系统先格式化出 inode 与 block的区块，假设一个文件的权限和属性是放在4号（白色方块），而这个 inode 记录了文件数据的实际的放置点为2，7，13，15这4个号码，此时我们就可以一次找到这4个block的内容！

这种数据访问的方式称为索引式文件系统（indexed allocation）。至于我们常用的U盘，使用的一般是FAT格式，这种格式的文件系统没有 inode 存在，所以每个block号码都记录在前一个block当中，如图所示：  
![在这里插入图片描述][SouthEast 1]  
我们经常听到“碎片整理”对吧，**需要碎片整理的原因就是文件写入的 block 太过于离散了，此时文件读取的性能将会变得很差所致。这个时候可以通过碎片整理将一个文件所属的block汇合在一起**，读取比较容易，一般来说，Ext2不太需要经常进行碎片整理，使用太久的话，也许需要。

### EXT2文件系统 ###

Linux的正规文件系统为Ext2 。文件系统一开始就将inode与block规划好了，除非重新格式化（后者利用resize2fs等命令更改文件），否则inode与block固定后就不再变动。但是如果我们的文件系统高达几百GB时，把所有的inode和block放在一起是很不明智的。

因此Ext2在格式化的时候基本上是分为多个块组（block group）的，每个块组都有独立的inode/block/superblock系统。在整体的规划当中，\*\*文件系统最前面有一个活动扇区（boot sector）， 这个启动扇区可以安装引导装载程序，\*\*这样我们就能够将不同的引导装载程序安装到个别的文件系统最前端，而不用覆盖整块硬盘的唯一MBR。  
![在这里插入图片描述][SouthEast 2]

#### data block（数据块） ####

data block是用来放置文件内容的地方，\*\*在Ext2文件系统中所支持的block大小有1kb、2kb以及4kb三种。\*\*在格式化时，block的大小就固定了，且每个block都有编号，以便inode记录。由于block大小的差异，会导致该文件系统能够支持的最大磁盘容量与最大单一文件容量并不相同。如下表格所示：

<table> 
 <thead> 
  <tr> 
   <th>Block大小</th> 
   <th>1KB</th> 
   <th>2KB</th> 
   <th>4KB</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>最大单一文件限制</td> 
   <td>16GB</td> 
   <td>256GB</td> 
   <td>2TB</td> 
  </tr> 
  <tr> 
   <td>最大文件系统容量</td> 
   <td>2TB</td> 
   <td>8TB</td> 
   <td>16TB</td> 
  </tr> 
 </tbody> 
</table>

除此之外，Ext2文件系统的block还有哪些限制？

*  原则上，block的大小与数量在格式化完就不能再改变了（除非重新格式化）
 *  每个block内最多只能够放置一个文件的数据
 *  如果文件大于block的大小，则就会占用多个block
 *  若文件小于block，则该block的剩余容量就不会被使用（磁盘空间浪费）

> 例题：  
> 假设你的Ext2文件系统使用4K block，而改文件系统中有10000个小文件，每个文件的大小均为50 bytes，请问此时磁盘浪费多少容量？由于一个block只能容纳一个文件，所以，每个block会浪费4046 bytes，所有文件仅为：50 x 10000(bytes) = 488.3KB，但浪费却达到了：4046 x 10000(bytes) = 38.6MB。所以合适的block大小很重要。

#### inodetable（inode表格） ####

前面已经说了，inode的内容主要记录文件的属性以及该文件实际数据的位置。基本上，它记录的文件数据有下面这些：

*  该文件的访问模式（read/write/execute）
 *  该文件的所有者与组（owner/group）
 *  该文件的大小的各个时间（ctime/atime/mtime）
 *  定义文件特征的标志（flag），如SUID等
 *  该文件真正内容的指向（pointer）
 *  每个inode大小固定为128bytes
 *  每个文件都仅会占用一个inode

\*\*因此文件系统能创建的文件数量与inode的数量有关。系统读取文件时需要找到inode，并分析inode所记录的权限与用户是否符合，若符合才能够开始实际读取block的内容。**下面我们来简单分析下inode/block与文件大小的关系。inode要记录的数据非常多，但是又只有128bytes，一个block占用4bytes。那如果我们的文件比较大，该怎么办？为此我们的**系统将inode记录block号码的区域定义为12个直接、一个间接、一个双间接、一个三间接记录区。\*\*如图所示：  
![在这里插入图片描述][SouthEast 3]  
以每个block的大小1KB为例来说，情况如下：

*  12个直接指向：12 x 1K = 12K
 *  间接：256 x 1K = 256K
 *  双间接：256 x 256 x 1K = 2562K
 *  三间接：256 x 256 x 256 = 256 3K

**总额：将上面的加在一起，可得到12 + 256 + 2562 \+ 2563(K) = 16GB**.我们这下也知道了前面的最大单一文件限制是怎么来的了。

#### superblock（超级块） ####

superblock主要是记录整个文件系统相关的地方，记录的主要信息有：

*  block与inode的总量，未使用和已使用的inode/block数量及总量
 *  block与inode的大小
 *  文件系统挂载时间、最近一次写入数据的时间、最近一次检验磁盘（fsck）时间等
 *  一个valid bit数值，若此文件系统已经被挂载，则valid bit为0，否则为1

#### File system description（文件系统描述说明） ####

这个区段可以描述每个block group的开始与结束的号码，以及说明每个区段（superblock、bitmap、inodemap、data block）分别介于哪个block号码之间。也能够用dumpe2fs查看。

#### block bitmap（块对照表） ####

我们可以通过block bitmap来知道哪些block是空的，此时系统就可以快速地找到可使用空间老放置文件。

#### inode bitmap（inode对照表） ####

这个和block bitmap的功能是类似的，只是inode bitmap记录的是使用与未使用的号码。

[SouthEast]: /images/20220404/9313c9c2f4d14e73abf85b02f375afa1.png
[SouthEast 1]: /images/20220404/715e48ddc8b648ad80c18dba7b3a8d3f.png
[SouthEast 2]: /images/20220404/02a866fa02c940b798658df1a597d376.png
[SouthEast 3]: /images/20220404/13c0bf67fab341dba26b9c8bd74a2fe5.png