第8章、 Linux 磁盘与文件系统管理

8.1. 认识 EXT2 文件系统
8.1.1. 硬盘组成与分割的复习
整颗磁盘的组成主要有：
- 圆形的磁盘；
- 机械手臂；
- 主轴马达；

数据储存与读取的重点在于磁盘，而磁盘上的物理组成则为：
- 扇区(Sector)为最小的物理储存单位，每个扇区为 512 bytes；
- 将扇区组成一个圆，那就是磁柱(Cylinder)，磁柱是分割槽(partition)的最小单位；
- 第一个扇区最重要，里面有：主要开机区(Master boot record, MBR)占有 446 bytes；分割表(partition table)占有 64 bytes。

各种接口的磁盘在Linux中的文件名分别为：
- /dev/sd[a-p][1-15]：为SCSI, SATA, USB, Flash随身碟等接口的磁盘文件名；
- /dev/hd[a-d][1-63]：为 IDE 接口的磁盘文件名；

磁盘分区意即指定分割槽的启始与结束磁柱就是了。

那么指定分割槽的磁柱范围是记录在第一个扇区的分割表中！但是因为分割表仅有64bytes而已， 因此最多只能记录四笔分割槽的记录，这四笔记录我们称为主要 (primary) 或延伸 (extended) 分割槽，其中延伸分割槽还可以再分割出逻辑分割槽 (logical) ， 而能被格式化的则仅有主要分割与逻辑分割而已。 分割的定义拿出来说明一下：
- 主要分割与延伸分割最多可以有四笔(硬盘的限制)
- 延伸分割最多只能有一个(操作系统的限制)
- 逻辑分割是由延伸分割持续切割出来的分割槽；
- 能够被格式化后，作为数据存取的分割槽为主要分割与逻辑分割。延伸分割无法格式化；
- 逻辑分割的数量依操作系统而不同，在Linux系统中，IDE硬盘最多有59个逻辑分割(5号到63号)， SATA硬盘则有11个逻辑分割(5号到15号)。

8.1.2. 文件系统特性： 索引式文件系统
磁盘分区完毕后还需要进行格式化(format)，之后操作系统才能够使用这个分割槽。『格式化』的原因是因为每种操作系统所设定的文件属性/权限并不相同， 为了存放这些档案所需的数据，因此就需要将分割槽进行格式化，以成为操作系统能够利用的『文件系统格式(filesystem)』。
每种操作系统能够使用的文件系统并不相同。 举例来说，windows 98 以前的微软操作系统主要利用的文件系统是 FAT (或 FAT16)，windows 2000 以后的版本有所谓的 NTFS 文件系统，至于 Linux 的正统文件系统则为 Ext2 (Linux second extended file system, ext2fs)这一个。此外，在默认的情况下，windows 操作系统是不会认识 Linux 的 Ext2 的。
传统的磁盘与文件系统的应用中，一个分割槽就是只能够被格式化成为一个文件系统，所以我们可以说一个 filesystem 就是一个 partition。但是由于新技术的利用，例如我们常听到的LVM与软件磁盘阵列(software raid)， 这些技术可以将一个分割槽格式化为多个文件系统(例如LVM)，也能够将多个分割槽合成一个文件系统(LVM, RAID) ！ 所以说，目前我们在格式化时已经不再说成针对 partition 来格式化了， 通常我们可以称呼一个可被挂载的数据为一个文件系统而不是一个分割槽！
文件系统的运作与操作系统的档案数据有关。较新的操作系统的档案数据除了档案实际内容外， 通常含有非常多的属性，例如 Linux 操作系统的档案权限(rwx)与文件属性(拥有者、群组、时间参数等)。 文件系统通常会将这两部份的数据分别存放在不同的区块，权限与属性放置到 inode 中，至于实际数据则放置到 data block 区块中。 另外，还有一个超级区块 (superblock) 会记录整个文件系统的整体信息，包括 inode 与 block 的总量、使用量、剩余量等。
每个 inode 与 block 都有编号，至于这三个数据的意义可以简略说明如下：
- superblock：记录此 filesystem 的整体信息，包括inode/block的总量、使用量、剩余量， 以及文件系统的格式与相关信息等；
- inode：记录档案的属性，一个档案占用一个inode，同时记录此档案的数据所在的 block 号码；
- block：实际记录档案的内容，若档案太大时，会占用多个 block 。

由于每个 inode 与 block 都有编号，而每个档案都会占用一个 inode ，inode 内则有档案数据放置的 block 号码。 因此，如果能够找到档案的 inode 的话，那么自然就会知道这个档案所放置数据的 block 号码， 当然也就能够读出该档案的实际数据了。这是个比较有效率的作法。
我们将 inode 与 block 区块用图解来说明一下，如下图所示，文件系统先格式化出 inode 与 block 的区块，假设某一个档案的属性与权限数据是放置到 inode 4 号(下图较小方格内)，而这个 inode 记录了档案数据的实际放置点为 2, 7, 13, 15 这四个 block 号码，此时我们的操作系统就能够据此来排列磁盘的阅读顺序，可以一口气将四个 block 内容读出来！ 那么数据的读取就如同下图中的箭头所指定的模样了。

这种数据存取的方法我们称为索引式文件系统(indexed allocation)。那有没有其他的惯用文件系统可以比较一下啊？ 有的，那就是我们惯用的随身碟(闪存)，随身碟使用的文件系统一般为 FAT 格式。FAT 这种格式的文件系统并没有 inode 存在，所以 FAT 没有办法将这个档案的所有 block 在一开始就读取出来。每个 block 号码都记录在前一个 block 当中， 他的读取方式有点像底下这样：

上图中我们假设档案的数据依序写入1->7->4->15号这四个 block 号码中， 但这个文件系统没有办法一口气就知道四个 block 的号码，他得要一个一个的将 block 读出后，才会知道下一个 block 在何处。 如果同一个档案数据写入的 block 分散的太过厉害时，则我们的磁盘读取头将无法在磁盘转一圈就读到所有的数据， 因此磁盘就会多转好几圈才能完整的读取到这个档案的内容！
需要碎片整理的原因就是档案写入的 block 太过于离散了，此时档案读取的效能将会变的很差。 这个时候可以透过碎片整理将同一个档案所属的 blocks 汇整在一起，这样数据的读取会比较容易！ FAT 的文件系统需要三不五时的碎片整理一下，那么 Ext2 是否需要磁盘重整呢？
由于 Ext2 是索引式文件系统，基本上不太需要常常进行碎片整理的。但是如果文件系统使用太久， 常常删除/编辑/新增档案时，那么还是可能会造成档案数据太过于离散的问题，此时或许会需要进行重整一下的。 不过，老实说，似乎不太需要啦！

8.1.3. Linux 的 EXT2 文件系统(inode): data block, inode table, superblock, dumpe2fs
Linux 的档案除了原有的数据内容外，还含有非常多的权限与属性，这些权限与属性是为了保护每个用户所拥有数据的隐密性。 而前一小节我们知道 filesystem 里面可能含有的 inode/block/superblock 等。标准的 Linux 文件系统 Ext2 就是使用这种 inode 为基础的文件系统！
inode 的内容在记录档案的权限与相关属性，至于 block 区块则是在记录档案的实际内容。 而且文件系统一开始就将 inode 与 block 规划好了，除非重新格式化(或者利用 resize2fs 等指令变更文件系统大小)，否则 inode 与 block 固定后就不再变动。如果我的文件系统高达数百GB时， 那么将所有的 inode 与 block 通通放置在一起将是很不智的决定，因为 inode 与 block 的数量太庞大，不容易管理。
因此 Ext2 文件系统在格式化的时候基本上是区分为多个区块群组 (block group) 的，每个区块群组都有独立的 inode/block/superblock 系统。整个来说，Ext2 格式化后有点像底下这样：

在整体的规划当中，文件系统最前面有一个启动扇区(boot sector)，这个启动扇区可以安装开机管理程序， 这是个非常重要的设计，因为如此一来我们就能够将不同的开机管理程序安装到个别的文件系统最前端，而不用覆盖整颗硬盘唯一的 MBR， 这样也才能够制作出多重引导的环境！至于每一个区块群组(block group)的六个主要内容说明如后：

1.data block (资料区块) ：
data block 是用来放置档案内容数据地方，在 Ext2 文件系统中所支持的 block 大小有 1K, 2K 及 4K 三种而已。在格式化时 block 的大小就固定了，且每个 block 都有编号，以方便 inode 的记录。 不过要注意的是，由于 block 大小的差异，会导致该文件系统能够支持的最大磁盘容量与最大单一档案容量并不相同。 因为 block 大小而产生的 Ext2 文件系统限制如下：

你需要注意的是，虽然 Ext2 已经能够支持大于 2GB 以上的单一档案容量，不过某些应用程序依然使用旧的限制， 也就是说，某些程序只能够捉到小于 2GB 以下的档案而已，这就跟文件系统无关了！
除此之外 Ext2 文件系统的 block 还有的限制如下：
- 原则上，block 的大小与数量在格式化完就不能够再变了(除非重新格式化)；
- 每个 block 内最多只能够放置一个档案的数据；
- 承上，如果档案大于 block 的大小，则一个档案会占用多个 block 数量；
- 承上，若档案小于 block ，则该 block 的剩余容量就不能够再被使用了(磁盘空间会浪费)。
如上第四点所说，由于每个 block 仅能容纳一个档案的数据，因此如果你的档案都非常小，但是你的 block 在格式化时却选用最大的 4K 时，可能会产生一些容量的浪费：

什么情况会产生上述状况呢？例如 BBS 网站的数据！如果 BBS 上面的数据使用的是纯文本档案来记载每篇留言， 而留言内容如果都写上『如题』时，想一想，是否就会产生很多小档案了呢？
既然大的 block 可能会产生较严重的磁盘容量浪费，那么我们是否就将 block 大小订为 1K 即可？ 这也不妥，因为如果 block 较小的话，那么大型档案将会占用数量更多的 block ，而 inode 也要记录更多的 block 号码，此时将可能导致文件系统不良的读写效能。
所以我们可以说，在您进行文件系统的格式化之前，请先想好该文件系统预计使用的情况。

2.inode table (inode 表格)：
如前所述 inode 的内容在记录档案的属性以及该档案实际数据是放置在哪几号 block 内！ 基本上，inode 记录的档案数据至少有底下这些：
- 该档案的存取模式(read/write/excute)；
- 该档案的拥有者与群组(owner/group)；
- 该档案的容量；
- 该档案建立或状态改变的时间(ctime)；
- 最近一次的读取时间(atime)；
- 最近修改的时间(mtime)；
- 定义档案特性的旗标(flag)，如 SetUID…；
- 该档案真正内容的指向 (pointer)；

inode 的数量与大小也是在格式化时就已经固定了，除此之外 inode 还有些什么特色呢？
- 每个 inode 大小均固定为 128 bytes；
- 每个档案都仅会占用一个 inode 而已；
- 承上，因此文件系统能够建立的档案数量与 inode 的数量有关；
- 系统读取档案时需要先找到 inode，并分析 inode 所记录的权限与用户是否符合，若符合才能够开始实际读取 block 的内容。

inode 要记录的数据非常多，但偏偏又只有 128bytes 而已， 而 inode 记录一个 block 号码要花掉 4byte ，假设我一个档案有 400MB 且每个 block 为 4K 时， 那么至少也要十万笔 block 号码的记录呢！inode 哪有这么多可记录的信息？为此我们的系统很聪明的将 inode 记录 block 号码的区域定义为12个直接，一个间接, 一个双间接与一个三间接记录区。这是啥？我们将 inode 的结构画一下好了。

上图最左边为 inode 本身 (128 bytes)，里面有 12 个直接指向 block 号码的对照，这 12 笔记录就能够直接取得 block 号码！ 至于所谓的间接就是再拿一个 block 来当作记录 block 号码的记录区，如果档案太大时， 就会使用间接的 block 来记录编号。如上图 1.3.2 当中间接只是拿一个 block 来记录额外的号码而已。 同理，如果档案持续长大，那么就会利用所谓的双间接，第一个 block 仅再指出下一个记录编号的 block 在哪里， 实际记录的在第二个 block 当中。依此类推，三间接就是利用第三层 block 来记录编号！ 这样子 inode 能够指定多少个 block 呢？我们以较小的 1K block 来说明好了，可以指定的情况如下：
- 12 个直接指向： 12*1K=12K
由于是直接指向，所以总共可记录 12 笔记录，因此总额大小为如上所示；
- 间接： 256*1K=256K
每笔 block 号码的记录会花去 4bytes，因此 1K 的大小能够记录 256 笔记录，因此一个间接可以记录的档案大小如上；
- 双间接： 256*256*1K=65536K
第一层 block 会指定 256 个第二层，每个第二层可以指定 256 个号码，因此总额大小如上；
- 三间接： 256*256*256*1K=16777216K
第一层 block 会指定 256 个第二层，每个第二层可以指定 256 个第三层，每个第三层可以指定 256 个号码，因此总额大小如上；
- 总额：将直接、间接、双间接、三间接加总，得到 12 + 256 + 256*256 + 256*256*256 (K) = 16GB

此时我们知道当文件系统将 block 格式化为 1K 大小时，能够容纳的最大档案为 16GB，比较一下文件系统限制表的结果可发现是一致的！但这个方法不能用在 2K 及 4K block 大小的计算中， 因为大于 2K 的 block 将会受到 Ext2 文件系统本身的限制，所以计算的结果会不太符合之故。

3.Superblock (超级区块) ：
Superblock 是记录整个 filesystem 相关信息的地方， 没有 Superblock ，就没有这个 filesystem 了。他记录的信息主要有：
- block 与 inode 的总量；
- 未使用与已使用的 inode / block 数量；
- block 与 inode 的大小 (block 为 1, 2, 4K，inode 为 128 bytes)；
- filesystem 的挂载时间、最近一次写入数据的时间、最近一次检验磁盘 (fsck) 的时间等文件系统的相关信息；
- 一个 valid bit 数值，若此文件系统已被挂载，则 valid bit 为 0 ，若未被挂载，则 valid bit 为 1 。

Superblock 是非常重要的，因为我们这个文件系统的基本信息都写在这里，因此，如果 superblock 死掉了， 你的文件系统可能就需要花费很多时间去挽救！一般来说， superblock 的大小为 1024bytes。相关的 superblock 讯息我们等一下会以 dumpe2fs 指令来呼叫出来观察！
此外，每个 block group 都可能含有 superblock ！但是我们也说一个文件系统应该仅有一个 superblock 而已，那是怎么回事啊？ 事实上除了第一个 block group 内会含有 superblock 之外，后续的 block group 不一定含有 superblock ， 而若含有 superblock 则该 superblock 主要是做为第一个 block group 内 superblock 的备份，这样可以进行 superblock 的救援！

4.Filesystem Description (文件系统描述说明) ：
这个区段可以描述每个 block group 的开始与结束的 block 号码，以及说明每个区段 (superblock, bitmap, inodemap, data block) 分别介于哪一个 block 号码之间。这部份也能够用 dumpe2fs 来观察的。

5.block bitmap (区块对照表) ：
想要新增档案时总会用到 block ，那你要使用那个 block 来记录。当然是选择『空的block 』来记录新档案的数据。 从 block bitmap 当中可以知道哪些 block 是空的，因此我们的系统就能够很快速的找到可使用的空间来处置档案。 同样的，如果你删除某些档案时，那么那些档案原本占用的 block 号码就得要释放出来， 此时在 block bitmpap 当中相对应到该 block 号码的标志就得要修改成为『未使用中』！这就是 bitmap 的功能。

6.inode bitmap (inode 对照表) ：
这个其实与 block bitmap 是类似的功能，只是 block bitmap 记录的是使用与未使用的 block 号码， 至于 inode bitmap 则是记录使用与未使用的 inode 号码！ 刚刚谈到的各部分数据都与 block 号码有关！ 每个区段与 superblock 的信息都可以使用 dumpe2fs 这个指令来查询的！查询的方法与实际的观察如下：




如上所示，利用 dumpe2fs 可以查询到非常多的信息，不过依内容主要可以区分为上半部是 superblock 内容， 下半部则是每个 block group 的信息了。从上面的表格中我们可以观察到这个 /dev/hdc2 规划的 block 为 4K， 第一个 block 号码为 0 号，且 block group 内的所有信息都以 block 的号码来表示的。 然后在 superblock 中还有谈到目前这个文件系统的可用 block 与 inode 数量！

至于 block group 的内容我们单纯看 Group0 信息好了。从上表中我们可以发现：
- Group0 所占用的 block 号码由 0 到 32767 号，superblock 则在第 0 号的 block 区块内！
- 文件系统描述说明在第 1 号 block 中；
- block bitmap 与 inode bitmap 则在 627 及 628 的 block 号码上。
- 至于 inode table 分布于 629-1641 的 block 号码中！
- 由于 (1)一个 inode 占用 128 bytes ，(2)总共有 1641 - 629 + 1(629本身) = 1013 个 block 花在 inode table 上， (3)每个 block 的大小为 4096 bytes(4K)。由这些数据可以算出 inode 的数量共有 1013 * 4096 / 128 = 32416 个 inode 啦！
- 这个 Group0 目前没有可用的 block 了，但是有剩余 32405 个 inode 未被使用；
- 剩余的 inode 号码为 12 号到 32416 号。

8.1.4. 与目录树的关系
由前一小节的介绍我们知道在 Linux 系统下，每个档案(不管是一般档案还是目录档案)都会占用一个 inode ， 且可依据档案内容的大小来分配多个 block 给该档案使用。而由第六章的权限说明中我们知道目录的内容在记录文件名， 一般档案才是实际记录数据内容的地方。那么目录与档案在 Ext2 文件系统当中是如何记录数据的呢？ 基本上可以这样说：

一、目录
当我们在 Linux 下的 ext2 文件系统建立一个目录时， ext2 会分配一个 inode 与至少一块 block 给该目录。其中，inode 记录该目录的相关权限与属性，并可记录分配到的那块 block 号码； 而 block 则是记录在这个目录下的文件名与该文件名占用的 inode 号码数据。也就是说目录所占用的 block 内容在记录如下的信息：

如果想要实际观察 root 家目录内的档案所占用的 inode 号码时，可以使用 ls -i 这个选项来处理：

由于每个人所使用的计算机并不相同，系统安装时选择的项目与 partition 都不一样，因此你的环境不可能与我的 inode 号码一模一样！上表的右边所列出的 inode 仅是我的系统所显示的结果而已！而由这个目录的 block 结果我们现在就能够知道， 当你使用『 ll / 』时，出现的目录几乎都是 1024 的倍数，为什么呢？因为每个 block 的数量都是 1K, 2K, 4K ！

由于根目录 /dev/hdc2 使用的 block 大小为 4K ，因此每个目录几乎都是 4K 的倍数。 其中由于 /sbin 的内容比较复杂因此占用了 3 个 block ，此外 /boot 为独立的 partition ， 该 partition 的 block 为 1K 而已，因此该目录就仅占用 1024 bytes 的大小！至于奇怪的 /proc 我们在第六章就讲过该目录不占硬盘容量！
由上面的结果我们知道目录并不只会占用一个 block 而已；

二、档案
当我们在 Linux 下的 ext2 建立一个一般档案时， ext2 会分配一个 inode 与相对于该档案大小的 block 数量给该档案。例如：假设我的一个 block 为 4 Kbytes ，而我要建立一个 100 KBytes 的档案，那么 linux 将分配一个 inode 与 25 个 block 来储存该档案！ 但同时请注意，由于 inode 仅有 12 个直接指向，因此还要多一个 block 来作为区块号码的记录！

三、目录树读取
经过上面的说明你也应该要很清楚的知道 inode 本身并不记录文件名，文件名的记录是在目录的 block 当中。 因此在第六章档案与目录的权限说明中， 我们才会提到『新增/删除/更名文件名与目录的 w 权限有关』的特色！那么因为文件名是记录在目录的 block 当中， 因此当我们要读取某个档案时，就务必会经过目录的 inode 与 block ，然后才能够找到那个待读取档案的 inode 号码， 最终才会读到正确的档案的 block 内的数据。
由于目录树是由根目录开始读起，因此系统透过挂载的信息可以找到挂载点的inode 号码(通常一个 filesystem 的最顶层 inode 号码会由 2 号开始！)，此时就能够得到根目录的 inode 内容，并依据该 inode 读取根目录的 block 内的文件名数据，再一层一层的往下读到正确的档名。
如果我想要读取 /etc/passwd 这个档案时，系统是如何读取的呢？