Linux 文件系统之初步思考

Posted 2020-10-13

 

---

 

数据存放在磁盘中，文件也是以数据形式存放的。因为磁盘中的数据是连续存放的，所以有必要对其进行管理。即 文件系统（FS)。

首先FS应独立于OS而存在，FS中存储的最小单位是 块（Block)，Block在创建FS时需指定其大小，通常（1KB,2KB,4KB...)

通常文件除了 其内部数据外，还有一些属性需要记录。如 权限，大小等, 即 metadata,

将metadata存放在一个叫 inode 中,而数据data则放在block中,(当然 ,inode本身也是存放在块中),于是一个文件对应了一个inode，现在将inode与block关联起来。

1，索引式，inode存放所有block的索引

2, 链接式 ,  inode存放首个block,然后每个block指向其下一个

至于目录，与普通文件相同，只是目录的内容是目录项，它应包含 该目录所有文件（含目录）名，及其inode的索引，方便我们能找到对应文件。

此外，为了对Block和inode进行管理，分配。还有个bitmap位图用与标识一个Block有无被使用.

---

 

Ext2文件系统

ext2文件系统结构如图:

 

说明：（此信息从外部复制引用，用背景色标注...以上图片也是拷贝的）

一、超级块（Super block）：

 描述整个分区的文件系统信息。

1、block与inode总量；

2、未使用与已使用的inode、block数量；

3、block与inode的大小； inode为128 Byte, block 大小格式化时指定

4、文件系统的挂载时间、最近一次写入数据的时间，最近一次检验磁盘的时间等文件系统的相关信息；

5、一个validbit数值，若此文件系统已挂载，则validbit为0，若未挂载，则validbit为1；

一般来说， superblock 的大小为 1024bytes。相关的 superblock 信息我们可以dumpe2fs 命令来呼叫出来观察！

超级块在每个块组的开头都有一份拷贝。事实上除了第一个 block group 内会含有 superblock 之外，后续的 block group 不一定含有 superblock ，

而若含则是第一个 block group 内 superblock 的备份，这样可以进行 superblock 的救援！

二、组描述符表（GDT，Group Descriptor Table）：

由很多块组描述符组成，整个分区分成多少个块组就对应有多少个块组描述符。每个块组描述符（Group Descriptor）存储一个块组的描述信息，例如在这个块组中从哪里开始是inode表，从哪里开始是数据块，空闲的inode和数据块还有多少个等等。和超级块类似，块组描述符表在每个块组的开头也都有一份拷贝，这些信息是非常重要的，一旦超级块意外损坏就会丢失整个分区的数据，一旦块组描述符意外损坏就会丢失整个块组的数据，因此它们都有多份拷贝。通常内核只用到第0个块组中的拷贝，当执行e2fsck检查文件系统一致性时，第0个块组中的超级块和块组描述符表就会拷贝到其它块组，这样当第0个块组的开头意外损坏时就可以用其它拷贝来恢复，从而减少损失。

 

三、位图 （bitmap) :

其中每个bit表示一个inode/Block是否空闲可用。

 

 

思考如下：(根据一些命令测试结果）

(说明: 至此之后,我将一个BLOCK的大小用B来表示，numi表示inode数量，numb表示block数量,numg表示group数量）

1，与物理磁盘如何对应以及分组大小怎么确定？

FS以块为最小的存储单位，那么直接将一个文件系统按block分隔，编号0~numb-1,

因为B一开始指定，分区大小/B,不足一1B忽视，得到numb.这样就与物理磁盘一一对应。

现在我不防先假定已知 blockgroup的分配策略，那么，inode表和数据表的偏移地址(即 在group的起始地址)能否确定?

根据dumpe2fs，块组中，Superblock占用 1B，bitmap占用1B，inodetable根据 (numi/numg*128)/B可知大小，

它们是连续的，位置关系如上面的图所示。所以，如果能确定GDT的大小，那么偏移地址还是很容易记算。

 

----（未完，暂存）