3Linux磁盘与档案系统管理.docx

《3Linux磁盘与档案系统管理.docx》由会员分享，可在线阅读，更多相关《3Linux磁盘与档案系统管理.docx（58页珍藏版）》请在三一办公上搜索。

1、Linux 磁盘与档案系统管理1认识 EXT2 档案系统1硬盘物理组成1磁盘分割 ( Partition )2档案系统3Linux 的 EXT2 档案系统( inode )4EXT2/EXT3 档案的存取与日志式档案系统的功能8数据的不一致 (Inconsistent) 状态11Linux 档案系统的运作12挂载点的意义 (mount point)13其它 Linux 支持的档案系统13档案系统的简单操作14磁盘与目录的容量14df14du17连结档的介绍： ln18# Hard Link (硬式连结或实际连结)19# Symbolic Link (符号连结，亦即是快捷方式)20关于目录的 l

2、ink 数量22磁盘的分割、格式化、检验与挂载23磁盘分割： fdisk24# 删除磁盘分割槽27新增磁盘分割槽28# 操作环境的说明30# 注意事项：31磁盘格式化31mkbootdisk (制作软盘开机片)33fdformat (进行软盘低阶格式化)33磁盘检验： fsck, badblocks33fsck34badblocks35sync35磁盘挂载与卸载36umount (将装置档案卸载)39磁盘参数修订39mknod39e2label40tune2fs41# hdparm41设定开机挂载43各式磁盘挂载与 中文编码挂载还有 USB 随身碟44挂载软盘44挂载 Windows 磁盘44

3、挂载 USB 随身碟45开机挂载 /etc/fstab 及 /etc/mtab45特殊装置 loop 挂载49建立大型档案49格式化49挂载50虚拟内存之建置50建立虚拟内存装置51建立虚拟内存档案51虚拟内存的限制53本章习题练习：53Linux 磁盘与档案系统管理我们在前面的档案权限介绍的章节当中，提到很多的权限与属性的观念，那么接下来要了解的是， 这些属性是记录在硬盘的那个地方？这里就要特别了解到 Linux 档案系统( filesystem )是如何记录档案， 与档案是如何被读取的啰！而要了解整个档案系统的观念，就不能不知道硬盘的组成组件！ 所以，在这个章节当中，我们由最基础的硬盘组成

4、组件介绍起，并介绍 inode 与连结文件等基本知识， 以及如何利用开机即可挂载的方式来使我们的各个 partition 可以在开机时就已经进行好挂载的动作喔！认识 EXT2 档案系统既然这个章节主要在探讨 Linux 的磁盘档案系统，所以我们当然就需要先来了解一下硬盘是个什么东西啦！ 首先，我们就来看一看硬盘的物理组成，了解了物理组成之后，再来说明一下怎么样进行硬盘的分割 (partition) 吧！硬盘物理组成就硬盘的物理组件来说，硬盘其实是由许许多多的圆形硬盘盘所组成的， 依据硬盘盘能够容纳的数据量，而有所谓的单碟 (一块硬盘里面只有一个硬盘盘) 或者是多碟 (一块硬盘里面含有多个硬盘盘

5、)的硬盘。在这里我们以单一个硬盘盘来说明，硬盘盘可由底下的图形来示意：图二、磁柱示意图图一、硬盘盘示意图首先，硬盘里面一定会有所谓的磁头 ( Head ) 在进行该硬盘盘上面的读写动作，而磁头是固定在机械手臂上面的，机械手臂上有多个磁头可以进行读取的动作。 而当磁头固定不动 (假设机械手臂不动) ，硬盘盘转一圈所画出来的圆就是所谓的磁道( Track )；而如同我们前面刚刚提到的，一块硬盘里面可能具有多个硬盘盘， 所有硬盘盘上面相同半径的那一个磁道就组成了所谓的磁柱( Cylinder )。例如上图二所示意，在两个硬盘盘上面的同一个磁道就是一个磁柱啦！ 这个磁柱也是磁盘分割( partitio

6、n )时的最小单位了； 另外，由圆心向外划直线，则可将磁道再细分为一个一个的扇区( Sector )，这个扇区就是硬盘盘上面的最小储存物理量了！ 通常一个 sector 的大小约为 512 Bytes 。以上就是整个硬盘的基本组件。在计算整个硬盘的储存量时，简单的计算公式就是：Cylinder x Head x Sector x 512 Bytes。另外，硬盘在读取时，主要是硬盘盘会转动， 利用机械手臂将磁头移动到正确的数据位置(单方向的前后移动)，然后将数据依序读出。 在这个操作的过程当中，由于机械手臂上的磁头与硬盘盘的接触是很细微的空间， 如果有抖动或者是脏污在磁头与硬盘盘之间时，就会造成

7、数据的损毁或者是实体硬盘整个损毁因此，正确的使用计算机的方式，应该是在计算机通电之后，就绝对不要移动主机，并免抖动到硬盘， 而导致整个硬盘数据发生问题啊！另外，也不要随便将插头拔掉就以为是顺利关机！ 因为机械手臂必须要归回原位，所以使用操作系统的正常关机方式，才能够有比较好的硬盘保养啊！ 因为他会让硬盘的机械手臂归回原位啊！磁盘分割 ( Partition )在了解了硬盘的物理组件之后，再接着下来介绍的就是硬盘的分割( Partition )啰！ 为什么要进行硬盘分割啊？！因为我们必须要告诉操作系统： 我这块硬盘可以存取的区域是由 A 磁柱到 B 磁柱，如此一来， 操作系统才能够控制硬盘磁头去

8、 A-B 范围内的磁柱存取数据；如果没有告诉操作系统这个信息， 那么操作系统就无法利用我们的硬盘来进行数据的存取了， 因为操作系统将无法知道他要去哪里读取数据啊！这就是磁盘分割( Partition )的重点了： 也就是记录每一个分割区( Partition )的起始与结束磁柱！好了，那么这个分割区的起始与结束磁柱的数据放在哪里呢？！那就是我们在 Linux 安装与多重开机技巧 那个章节提到的 主要开机扇区( Master Boot Recorder, MBR )啰！事实上， MBR 就是在一块硬盘的第零轨上面，这也是计算机开机之后要去利用该硬盘时， 必须要读取的第一个区域！在这个区域内记录的

9、就是硬盘里面的所有分割信息， 以及开机的时候可以进行开机管理程序的写入的处所啊！所以，当一个硬盘的 MBR 坏掉时，由于分割的数据不见了，呵呵，那么这个硬盘也就几乎可以说是寿终正寝了， 因为操作系统不知道该去哪个磁柱上读取数据啊那么 MBR 有什么限制呢？他最大的限制来自于他的大小不够大到储存所有分割与开机管理程序的信息， 因此，MBR 仅提供最多四个 partition 的记忆，这就是所谓的 Primary (P)与 Extended (E) 的 partition 最多只能有四个的原因了。所以说，如果你预计分割超过 4 个 partition 的话，那么势必需要使用 3P + 1E ，并且

10、将所有的剩余空间都拨给 Extended 才行( 记得呦！ Extended 最多只能有一个 )，否则只要 3P + E 之后还有剩下的空间， 那么那些容量将成为废物而浪费了，所以结论就是 如果您要分割硬盘时，并且已经预计规划使用掉 MBR 所提供的 4 个 partition ( 3P + E 或 4P )那么磁盘的全部容量需要使用光，否则剩下的容量也不能再被使用。 不过，如果您仅是分割出 1P + 1E 的话，那么剩下的空间就还能再分割两个 primary partition ！档案系统在告知系统我的 partition 所在的起始与结束磁柱之后，再来则是需要将 partition 格式化

11、为我的操作系统认识的档案系统( Filesystem )啰！因为每个操作系统认识的 filesystem 并不相同！例如 Windows 操作系统在预设状态下就无法认识 Linux 的档案系统 ( 这里指 Linux 的标准档案系统 ext2 )。所以当然要针对我们的操作系统来格式化 partition 啰！我们可以说，每一个 partition 就是一个 Filesystem ，那么一个 partition 是否可以具有两个 Filesystem 呢？！理论上应该是不行的！因为每个档案系统都有其独特的支持方式，例如 Linux 的 ext3 就无法被 Windows 系统所读取！而你将一个

12、partition 格式化的时候，总不能格式化为 ext3 也同时格式化为 fat32 吧？！那是不可能的啊！不论是哪一种 filesystem ，数据总是需要储存的吧！既然硬盘是用来储存数据的，想当然尔， 数据就必须写入硬盘啦！刚刚我们提到硬盘的最小储存单位是 sector ，不过数据所储存的最小单位并不是 sector 喔，因为用 sector 来储存太没有效率了。怎么说呢？因为一个 sector 只有 512 Bytes ，而磁头是一个一个 sector 的读取，也就是说，如果我的档案有 10 MBytes ，那么为了读这个档案， 我的磁头必须要进行读取 (I/O) 20480 次！为了

13、克服这个效率上的困扰，所以就有逻辑区块( Block )的产生了！ 逻辑区块是在 partition 进行 filesystem 的格式化时， 所指定的最小储存单位，这个最小储存单位当然是架构在 sector 的大小上面( 因为 sector 为硬盘的最小物理储存单位啊！ )，所以啦， Block 的大小为 sector 的 2 的次方倍数。此时，磁头一次可以读取一个 block ，如果假设我们在格式化的时候，指定 Block 为 4 KBytes ( 亦即由连续的八个 sector 所构成一个 block )，那么同样一个 10 MBytes 的档案， 磁头要读取的次数则大幅降为 2560

14、次，这个时候可就大大的增加档案的读取效能啦！不过，Block 单位的规划并不是越大越好喔！怎么说呢？因为一个 Block 最多仅能容纳一个档案 (这里指 Linux 的 ext2 档案系统)！这有什么问题呢？举例来说好了，假如您的 Block 规划为 4 KBytes ，而您有一个档案大小为 0.1 KBytes ，这个小档案将占用掉一个 Block 的空间，也就是说，该 Block 虽然可以容纳 4 Kbytes 的容量，然而由于档案只占用了 0.1 Kbytes ，所以，实际上剩下的 3.9 KBytes 是不能再被使用了，所以，在考虑 Block 的规划时，需要同时考虑到： * 档案读取

15、的效能 * 档案大小可能造成的硬盘空间浪费因此，在规划您的磁盘时，需要留意到您主机的用途来进行规划较佳！例如 BBS 主机由于文章较短， 也就是说档案较小，那么 Block 小一点的好；而如果您的主机主要用在储存大容量的档案， 那么考虑到效能，当然 Block 理论上，规划的大一点会比较妥当啦！Superblock：如同前面说的，当我们在进行磁盘分割( partition )时，每个磁盘分割槽( partition )就是一个档案系统( filesystem )， 而每个档案系统开始的位置的那个 block 就称为 superblock ，superblock 的作用是储存像是档案系统的大小、

16、空的和填满的区块，以及他各自的总数和其它诸如此类的信息等等， 这也就是说，当您要使用这一个磁盘分割槽( 或者说是档案系统 )来进行数据存取的时候，第一个要经过的就是 superblock 这个区块了，所以啰， superblock 坏了，您的这个磁盘槽大概也就回天乏术了！Linux 的 EXT2 档案系统( inode )看完了上面的说明，您应该对于硬盘有一定程度的认识了！好了，那么接下来就是要谈一谈 Linux 的档案系统( Filesystem )啰！我们这里以 Linux 最标准的 ext2 这个档案系统来作为说明。还记得我们在 Linux 档案属性与目录配置 那个章节提到的，在 Lin

17、ux 系统当中，每个档案不止有档案的内容数据，还包括档案的种种属性，例如：所属群组、 所属使用者、能否执行、档案建立时间、档案特殊属性等等。由于 Linux 操作系统是一个多人多任务的环境，为了要保护每个使用者所拥有数据的隐密性， 所以具有多样化的档案属性是在所难免的！在标准的 ext2 档案系统当中，我们将每个档案的内容分为两个部分来储存，一个是档案的属性，另一个则是档案的内容。为了应付这两个不同的咚咚，所以 ext2 规划出 inode 与 Block 来分别储存档案的属性( 放在 inode 当中 )与档案的内容( 放置在 Block area 当中 )。当我们要将一个 partitio

18、n 格式化( format )为 ext2 时，就必须要指定 inode 与 Block 的大小才行，也就是说，当 partition 被格式化为 ext2 的档案系统时，他一定会有 inode table 与 block area 这两个区域。Block 已经在前面说过了，他是数据储存的最小单位。那么 inode 是什么？！简单的说， Block 是记录档案内容数据的区域，至于 inode 则是记录该档案的相关属性，以及档案内容放置在哪一个 Block 之内的信息。 简单的说， inode 除了记录档案的属性外，同时还必须要具有指向( pointer )的功能，亦即指向档案内容放置的区块之中

19、，好让操作系统可以正确的去取得档案的内容啊！ 底下几个是 inode 记录的信息(当然不止这些)： * 该档案的拥有者与群组(owner/group)； * 该档案的存取模式(read/write/excute)； * 该档案的类型(type)； * 该档案建立或状态改变的时间(ctime)、最近一次的读取时间(atime)、最近修改的时间(mtime)； * 该档案的容量； * 定义档案特性的旗标(flag)，如 SetUID.； * 该档案真正内容的指向 (pointer)；我们在前一章 Linux 档案与目录管理 当中提到过利用 ls 查询档案所记载的时间，就是 atime / ctim

20、e / mtime 三种时间。这三种时间的意义我们已经在前一章的 touch 指令介绍时提过，这三种时间就是记录在 inode 里面的啦 如果回到前一章，您会发现，我们可以利用 ls 的相关功能来查询到时间喔！而预设的显示时间是 mtime 。rootlinux # ls -la -time=atime PATH那个 PATH 是您所想要查询的档案或目录名称。利用上面的 ls 相关参数，就可以取得您想要知道的档案相关的三种时间啰 至于一个 inode 的大小为 128 bytes 这么大 (可以使用底下要介绍的 dumpe2fs 来查阅 inode 的大小喔！) ！好了，那么我的 Linux

21、系统到底是如何读取一个档案的内容呢？底下我们分别针对目录与档案来说明： * 目录： 当我们在 Linux 下的 ext2 档案系统建立一个目录时， ext2 会分配一个 inode 与至少一块 Block 给该目录。其中，inode 记录该目录的相关属性，并指向分配到的那块 Block ；而 Block 则是记录在这个目录下的相关连的档案(或目录)的关连性！ * 档案： 当我们在 Linux 下的 ext2 建立一个一般档案时， ext2 会分配至少一个 inode 与相对于该档案大小的 Block 数量给该档案。例如：假设我的一个 Block 为 4 Kbytes ，而我要建立一个 100

22、KBytes 的档案，那么 linux 将分配一个 inode 与 25 个 Block 来储存该档案！要注意的是， inode 本身并不纪录文件名，而是记录档案的相关属性，至于文件名则是记录在目录所属的 block 区域！ 那么档案与目录的关系又是如何呢？就如同上面的目录提到的，档案的相关连结会记录在目录的 block 数据区域， 所以当我们要读取一个档案的内容时，我们的 Linux 会先由根目录 / 取得该档案的上层目录所在 inode ， 再由该目录所记录的档案关连性 (在该目录所属的 block 区域) 取得该档案的 inode ， 最后在经由 inode 内提供的 block 指向，

23、而取得最终的档案内容。我们以 /etc/crontab 这个档案的读取为例， 他的内容数据是这样取得的：图三、读取 /etc/crontab 的简易流程示意。一块 partition 在 ext2 底下会被格式化为 inode table 与 block area 两个区域， 所以在图三里面，我们将 partition 以长条的方式来示意，会比较容易理解的啦！而读取 /etc/crontab 的流程为： 1. 操作系统根据根目录( / )的相关资料可取得 /etc 这个目录所在的 inode ，并前往读取 /etc 这个目录的所有相关属性； 2. 根据 /etc 的 inode 的资料，可以取

24、得 /etc 这个目录底下所有档案的关连数据是放置在哪一个 Block 当中，并前往该 block 读取档案的关连性内容； 3. 由上个步骤的 Block 当中，可以知道 crontab 这个档案的 inode 所在地，并前往该 inode ； 4. 由上个步骤的 inode 当中，可以取得 crontab 这个档案的所有属性，并且可前往由 inode 所指向的 Block 区域，顺利的取得 crontab 的档案内容。整个读取的流程大致上就是这样，如果您想要实作一下以了解整个流程的话，可以这样试做看看：1. 察看一下根目录所记载的所有档案关连性数据rootlinux # ls -lia /

25、2 drwxr-xr-x 24 root root 4096 Jul 16 23:45 . 2 drwxr-xr-x 24 root root 4096 Jul 16 23:45 . 719489 drwxr-xr-x 83 root root 12288 Jul 21 04:02 etc 523265 drwxr-xr-x 24 root root 4096 Jun 25 20:16 var# 注意看一下，在上面的 . 与 . 都是连结到 inode 号码为 2 的那个 inode ，# 也就是说， / 与其上层目录 . 都是指向同一个 inode number 啊！两者是相同的。# 而在根

26、目录所记载的档案关连性 (在 block 内) 得到 /etc 的 inode number # 为 719489 那个 inode number 喔！2. 察看一下 /etc/ 内的档案关连性的数据rootlinux # ls -liad /etc/crontab /etc/.719489 drwxr-xr-x 83 root root 12288 Jul 21 04:02 /etc/.723496 -rw-r-r- 1 root root 663 Jul 4 12:03 /etc/crontab# 瞧！此时就能够将 /etc/crontab 找到关连性啰！所以您知道，目录的最大功能就是在提

27、供档案的关连性，在关连性里面， 当然最主要的就是档名与 inode 的对应数据啰！另外，关于 EXT2 档案系统，这里有几点小事情要提醒一下： * ext2 与 ext3 档案在建立时 (format) 就已经设定好固定的 inode 数与 block 数目了； * 格式化 Linux 的 ext2 档案系统，可以使用 mke2fs 这个程序来执行！ * ext2 允许的 block size 为 1024, 2048 及 4096 bytes； * 一个 partition (filesystem) 所能容许的最大档案数，与 inode 的数量有关， 因为一个档案至少要占用一个 inode

28、啊！ * 在目录底下的档案数如果太多而导致一个 Block 无法容纳的下所有的关连性数据时，Linux 会给予该目录多一个 Block 来继续记录关连数据； * 通常 inode 数量的多寡设定为 (partition 的容量) 除以 (一个 inode 预计想要控制的容量)。 举例来说，若我的 block 规划为 4Kbytes，假设我的一个 inode 会控制两个 block ，亦即是假设我的一个档案大致的容量在 8Kbytes 左右时，假设我的这个 partition 容量为 1GBytes， 则 inode 数量共有：( 1G * 1024M/G * 1024K/M ) / ( 8K

29、) = 131072 个。而一个 inode 占用 128 bytes 的空间，因此格式化时就会有 ( 131072个 * 128bytes/个 ) = 16777216 byes = 16384 Kbytes 的 inode table 。也就是说，这一个 1GB 的 partition 在还没有储存任何数据前， 就已经少了 16MBytes 的容量啊！ * 因为一个 inode 只能记录一个档案的属性，所以 inode 数量比 block 多是没有意义的！ 举上面的例子来说，我的 Block 规划为 4 Kbytes ，所以 1GB 大概就有 262144 个 4Kbytes 的 bloc

30、k ，如果一个 block 对应一个 inode 的话，那么当我的 inode 数量大于 262144 时，多的 inode 将没有任何用处，徒然浪费硬盘的空间而已！另外一层想法，如果我的档案容量都很大， 那么一个档案占用一个 inode 以及数个 block ，当然 inode 数量就可以规划的少很多啦！ * 当 block 大小越小，而 inode 数量越多，则可利用的空间越多，但是大档案写入的效率较差； 这种情况适合档案数量多，但是档案容量小的系统，例如 BBS 或者是新闻群组( News )这方面服务的系统； * 当 Block 大小越大，而 inode 数量越少时，大档案写入的效率较

31、佳，但是可能浪费的硬盘空间较多； 这种状况则比较适合档案容量较大的系统！简单的归纳一下， ext2 有几个特色： * Blocks 与 inodes 在一开始格式化时 (format) 就已经固定了； * 一个 partition 能够容纳的档案数与 inode 有关； * 一般来说，每 4Kbytes 的硬盘空间分配一个 inode ； * 一个 inode 的大小为 128 bytes； * Block 为固定大小，目前支持 1024/2048/4096 bytes 等； * Block 越大，则损耗的硬盘空间也越多。 * 关于单一档案： 若 block size=1024，最大容量为 1

32、6GB，若 block size=4096，容量最大为 2TB； * 关于整个 partition ： 若 block size=1024，则容量达 2TB，若 block size=4096，则容量达 32TB。 * 文件名最长达 255 字符，完整文件名长达 4096 字符。 另外，关于 partition 的使用效率上，当您的一个 partition 规划的很大时，例如 100GB 这么大， 由于硬盘上面的数据总是来来去去的，所以，整个 partition 上面的档案通常无法连续写在一起， 而是填入式的将数据填入没有被使用的 block 当中。如果档案写入的 block 真的分的很散，

33、此时就会有所谓的档案离散的问题发生了。虽然我们的 ext2 在 inode 处已经将该档案所记录的 block number 都记上了，所以资料可以一次性读取，但是如果档案真的太过离散，确实还是会发生读取效率低落的问题。 果真如此，那么可以将整个 partition 内的数据全部复制出来，将该 partition 重新格式化， 再将数据给他复制回去即可解决。此外，如果 partition 真的太大了，那么当一个档案分别记录在这个 partition 的最前面与最后面的 block， 此时会造成硬盘的机械手臂移动幅度过大，也会造成数据读取效能的低落。因此， partition 的规划并不是越大越

34、好， 而是真的要针对您的主机用途来进行规划才行！_EXT2/EXT3 档案的存取与日志式档案系统的功能综合上面谈的种种，我们可以知道，当一个 ext2 的 filesystem 被建立时， 他拥有 superblock / group description / block bitmap / inode bitmap / inode table / data blocks 等等区域。要注意的是，每个 ext2 filesystem 在被建立的时候，会依据 partition 的大小， 给予数个 block group ，而每个 block group 就有上述的这些部分。整个 filesyst

35、em 的架构可以下图展现：图四、整个 filesystem 的展现示意图我们将整个 filesystem 简单化， 假设仅有一个 block group ，那么上面的各个部分分别代表什么呢？ * SuperBlock：如前所述， Superblock 是记录整个 filesystem 相关信息的地方， 没有 Superblock ，就没有这个 filesystem 了。他记录的信息主要有： o block 与 inode 的总量； o 未使用与已使用的 inode / block 数量； o 一个 block 与一个 inode 的大小； o filesystem 的挂载时间、最近一次写入数据

36、的时间、最近一次检验磁盘 (fsck) 的时间等档案系统的相关信息； o 一个 valid bit 数值，若此档案系统已被挂载，则 valid bit 为 0 ，若未被挂载，则 valid bit 为 1 。 * Group Description：纪录此 block 由由何处开始记录； * Block bitmap：此处记录那个 block 有没有被使用； * Inode bitmap：此处记录那个 inode 有没有被使用； * Inode table：为每个 inode 数据存放区； * Data Blocks：为每个 block 数据存放区。如果想要知道某个 ext2/ext3 的档案

37、系统内，关于上述提到的相关信息时，可以使用 dumpe2fs 这个指令来读取，举例来说，鸟哥将我自己的主机 /dev/hda1 读出 ext3 的讯息：rootlinux # dumpe2fs /dev/hda1Filesystem volume name: /Filesystem state: cleanErrors behavior: ContinueFilesystem OS type: LinuxInode count: 1537088Block count: 1536207Free blocks: 735609Free inodes: 1393089First block: 0Blo

38、ck size: 4096Filesystem created: Sat Jun 25 16:21:13 2005Last mount time: Sat Jul 16 23:45:04 2005Last write time: Sat Jul 16 23:45:04 2005Last checked: Sat Jun 25 16:21:13 2005First inode: 11Inode size: 128Journal inode: 8Group 0: (Blocks 0-32767) Primary superblock at 0, Group descriptors at 1-1 R

39、eserved GDT blocks at 2-376 Block bitmap at 377 (+377), Inode bitmap at 378 (+378) Inode table at 379-1400 (+379) 0 free blocks, 32424 free inodes, 11 directories Free blocks: Free inodes: 281-32704Group 1: (Blocks 32768-65535) Backup superblock at 32768, Group descriptors at 32769-32769 Reserved GD

40、T blocks at 32770-33144 Block bitmap at 33145 (+377), Inode bitmap at 33146 (+378) Inode table at 33147-34168 (+379) 18 free blocks, 24394 free inodes, 349 directories Free blocks: 37882-37886, 38263-38275 Free inodes: 38084-38147, 39283-39343, 41135, 41141-65408# 因为数据很多，所以鸟哥略去了一些信息了上面是比较精简的显示内容。# 在

41、 Group 0 之前的都是 Superblock 的内容，记录了 inode/block 的总数，# 还有其它相关的讯息。至于由 Group 0 之后，则是说明各个 bitmap 及 inode table # 与 block area 等等。透过这些记录，我们可以很轻易的就知道哪些 inode 没有被使用，哪些 block 还可以记录， 如此一来，在新增、建立档案与目录时，系统就会根据这些记录来将数据分别写入尚未被使用的 inode 与 block area 了！ 不过，要注意的是，当我们新增一个档案(目录)时： 1. 根据 inode bitmap / block bitmap 的信息，

42、找到尚未被使用的 inode 与 block ， 进而将档案的属性与数据分别记载进 inode 与 block ； 2. 将刚刚被利用的 inode 与 block 的号码 (number) 告知 superblock、inode bitmap、block bitmap 等，让这些 metadata 更新信息。 一般来说，我们将 inode table 与 block area 称为数据存放区域，至于其它的例如 superblock、 block bitmap 与 inode bitmap 等记录就被称为 metadata 啰。经由上面两个动作，我们知道一笔数据写入硬盘时， 会有这两个动作。数

43、据的不一致 (Inconsistent) 状态那么万一您的档案在写入硬盘时，因为不知名原因导致系统中断(例如突然的停电啊、 系统核心发生错误啊等等的怪事发生时)，所以数据就只有纪录到动作一，而动作二尚未进行 这就会产生 metadata 与数据存放区产生不一致 (Inconsistent) 的情况发生了。在早期的 EXT2 档案系统中，如果发生这个问题，那么系统在重新开机的时候， 就会藉由 Superblock 当中记录的 valid bit 与 filesystem state 等状态来判断是否强制进行数据一致性的检查！检查则以 e2fsck 这支程序来进行的。 不过，这样的检查真的是很费时

44、因为要针对 metadata 区域与实际数据存放区来进行比对， 呵呵得要搜寻整个 partition 呢哇！系统真忙碌而且在对 Internet 提供服务的服务器主机上面， 这样的检查真的会造成主机复原时间的拉长真是麻烦这也就造成后来所谓日志式档案系统的兴起了。稍微了解了所谓数据不一致的状态后，再来要了解的，就是，那么为何要有日志式档案系统的产生呢？ 我们已经在 Linux 档案属性与目录配置 当中提到过一些档案系统的注意事项， 也提过日志式 (Journal) 档案系统的相关功能，这里我们再稍微深入的讨论一下。刚刚提到了，在 EXT2 档案系统当中，要进行档案的写入时，会将数据分别在数据存放

45、区与 metadata 区记录下来， 若当这两个动作无法一次完成时，就会造成所谓的不一致现象。若发生不一致现象， 因为系统不知道是那个档案发生不一致现象，所以就会将整个 filesystem 做一致性的检查，如此一来，很费时啊！ 想一想，如果在我们的 filesystem 当中，要是能够规划出一个区块，专门来记录写入或修订档案时的步骤， 那不就可以简化一致性检查的步骤了？也就是说： 1. 当系统要写入一个档案的时候，会先在日志记录区块中纪录：某个档案准备要写入磁盘了； 2. 开始写入档案的权限与数据； 3. 开始更新 metadata 的数据； 4. 完成数据与 metadata 的更新后，在

46、日志记录区块当中完成该档案的纪录。在这样的程序当中，万一数据的纪录过程当中发生了问题，那么我们的系统只要去检查日志记录区块， 就可以知道那个档案发生了问题，针对该问题来做一致性的检查即可，而不必针对整块 filesystem 去检查， 真的就可以达到快速修复 filesystem 的能力了！这就是日志式档案最基础的功能啰 那么我们的 ext2 可达到这样的功能吗？当然可以啊！ 就透过 ext3 即可！ ext3 是 ext2 的升级版本，并且可向下兼容 ext2 版本呢！ 所以啰，目前我们才建议大家，可以直接使用 ext3 这个 filesystem 啊！ _如果您对于 EXT2 / EXT3 系统还有更多的兴趣，可以参考底下这几篇文章： * Design and Implementation of the Second Extended Filesystem * The