戏说文件系统之ext3【上】

今天我们简单聊一哈ext3文件系统。ext3作为ext2的增强版，和ext2使用的superblock、inode、group descriptor等数据结构几乎一模一样，所以ext3前向兼容ext2。在不用备份ext2文件系统数据的情况下，可以用：

tune2fs –j /dev/hdName

在不用卸载分区的状态下直接将ext2文件系统转换成ext3文件系统。

至于ext3的好处和优势我就不在这里废话了，今天我们先来和ext3文件系统打个招呼。

假如说，我们在编辑文件时，突然停电了、或系统被锁定被迫得重启，会出现什么后果？轻则文件丢失部分内容，重则整个文件内容混乱，更有甚者文件系统直接崩溃。这将会是多么可怕的一件事儿。在linux正常关机时我们都会看到一条卸载文件系统的打印信息，而非正常关机会导致文件系统出现不一致，在系统重新启动阶段挂文件系统时会发现这种不一致，然后它便会尝试去修复它。不幸的是，随着存储设备容量的增大，这种修复工作所花费的时间越来越无法让人容忍。而ext3文件系统就是在这种场合下噼里啪啦的诞生了。

Ext3的最大特性就是在ext2的基础上增加了日志功能，所以ext3文件系统也经常被人们称之为日志文件系统，但日志文件系统觉不仅仅只有ext3，还有诸如JFS、reiserFS和XFS，以及我们在Windows上经常见到的NTFS等。

Ext3的日志特性主要是依靠其下层一个名为“日志块设备层”的中间设备来完成，叫做JBD(Journaling Block Device layer 简称JBD)。JBD并不是文件系统规范的一部分，它和ext3文件系统的规范是没有任何的关系的，而JBD正是文件系统事务处理功能的实现基础。简而言之，JBD 被设计成在任何块设备上实现日志的特殊目的(越说越抽象，事务是个啥玩意儿啊⊙﹏⊙….)

关于事务，有过数据库开发经验或者做数据运维的筒子肯定不会陌生。这里咱不就结概念，也不拘泥学术定义，大家只要知道事务的主要作用就是为了保证操作的原子性。这句话如何理解？比如说，在金融系统中，要从账户A转账X元到账户B。这一业务必须要确保从A账户成功划出了X元，然后往B账户成功增加了X元。只有这两个操作同时成功才能任务是转账成功，任何一个操作失败该业务必须终止。假如从A账户转出X元成功，当往B账户写入时出现了错误，那么从A账户转出的X元必须被退还到A账户。更极端的情况是，此时A账户所在的数据由于种种原因又崩溃了，那么数据库的事务机制必须保证A账户的X元不会丢失。这就是数据库业务操作的原子性。在日志文件系统中这种对文件数据操作的原子性是由JBD来提供保证，Ext3 通过“钩入（hooking in）”JBD的API 来实现其日志记录的功能。JBD层本身虽然代码不多，但却是个相当复杂的软件部分，这里我们先不鸟它，以后有机会再陪它玩玩儿。
    日志文件系统当然要记录日志，而日志也需要占存储空间。所以，日志文件系统就是在存储介质上开辟一个块特殊的区域专门用于存储日志信息：

Ext3文件系统提供了三种记录日志的方式：

日志模式data=journal：这种模式会记录所有对文件数据和元数据的修改。

首先将元数据和数据写进日志，然后再写进相应的磁盘位置。该方式提供了很高安全性，不论系统在元数据写入日志阶段还是实际数据写入日志阶段发生崩溃，均不影响实际的主文件系统。这种模式将丢失数据的风险降到最低但也付出了效率的代价，因为所有数据都要写入两次。

顺序模式data=ordered：这种模式只会记录对文件系统元数据的修改。

首先将文件数据写入磁盘，然后将元数据写进日志，最后再把元数据写进磁盘。通过记录元数据的方式足以恢复磁盘文件系统数据结构的一致性，但由于文件数据不写入日志的原因，还是无法防止系统故障对文件内容造成的损害。

回写模式data=writeback：这种模式也只记录对元数据的修改。

先把数据写入磁盘，然后将元数据先写入日志再写入磁盘。但数据和元数据的写入没有固定的先后顺序。这种模式由于对文件数据的更改和文件元数据的修改时异步进行的，所以有可能出现文件系统中元数据不一致的情况。

我们可以看到就算是日志文件系统它也只是保证了系统调用级的一致性，不能完全杜绝数据的丢失。还是让我们实际探究一个ext3文件系统吧。

我新增一个IDE的硬盘/dev/hdb，大小为8G，为之划分一个分区/dev/hdb1，将其格式化成ext3文件系统：

    缺省情况下，block大小为4096字节，日志占据32768个block(约占128MB)。我们再看一下ext3文件系统信息一览表：

    和ext2采用默认值格式化分区的结果几乎一模一样，而差别就在于在filesystem features多了个has_journal的属性，详细如下所示：

    这里有个参数比较蹊跷：就是Free blocks。Ext3的日志文件大小为128M，应该只占了32768(128MB/4096=32768)个block。现在/dev/hdd1分区被格式化后里面除了一个lost+foud目录之外什么也没有，而ext3的free blcoks显示的是2026744，加上32768也才是2059512，不等于ext2所展示的2059546，还差34个block。这到底是肿么回事？我们来看一下ext3文件系统的日志空间的详情。
    默认情况下，日志占据了ext3文件系统的8号inode，其详情如下：

    日志空间确实是134217728字节，一共占据了32802个block，其中数据块的编号是从0开始，到32768，占32769个block，两级块指针32个，1个三级块指针。
    照这个输出结果来看，数据块大小应该是32769×4096=134221824字节，但上面我们看到ext3文件系统却认为它的日志空间是134217728字节。这里比较蹊跷，暂时还不晓得是什么原因，希望知道内幕的高手、大侠、前辈、大牛们给予指点。

    可以看到ext3的日志空间不但占完了Group0的所有数据块，还占据了Group1里2094个数据block。因此，我们可以很容易的画出/dev/hdb1这块硬盘上ext3文件系统日志所占的空间，如下：

    未完，待续...