ext2/ext3档案的存取与日志式文件系统功能

如何是新建一个档案或者目录时，我们的ext2是如何处理的呢？这个时候就要block bitmap以及inode bitmap的帮忙了。假设我们新增一个档案，此时文件系统的行为是：

1. 先确定用户对于欲新增档案的目录是否具有w与x的权限，若有的话才能新增；
2. 根据inode bitmap找到没有使用的inode号码，并将实际的数据写入到block中，并且更新inode的block指向数据；
3. 根据block bitmap找到没有使用的block号码，并将实际的数据写入到block中，并且更新inode的block指向数据；

4. 将刚刚写入的inode与block数据同步更新inode bitmap与block bitmap，并且更新superblock的内容；

   一般来说，我们将inode table与data block成为数据存放区，至于其他例如superblock 、block bitmap与inode bitmap等区段称为metadata罗。因为superblock，inode bitmap以及block bitmap的数据是经常变动的，每次新增/移除/编辑时都可能会影响到这三个部分的数据，因此称为中介数据了。

数据的不一致状态（Inconsistent）状态

在一般正常的情况下，上述的新增状态当然可以顺利完成。但是有个万一怎么办？例如你的档案在写入文件系统时，因为不知名原因导致系统中断（例如突然的停电，系统核心发送错误啦），所以写入的数据仅有inode table以及data block而已，最后一个同步更新中介数据的步骤并没有做完，此时就会发生metadata的内容与实际数据存放区产生不一致的情况了。

既然有不一致当然要克服。在早期的ext2文件系统中，如果发生这个问题，那么系统在重新启动的时候，就会由superblock当中记录得valid bit(是否有挂载)与filesystem state（clean与否）等状态来判断是否强行数据一致性的检查。若有需要时则以e2fsck这支程序来进行。

不过，这样的检查真是很费力，因为要针对metadata区域与实际数据存放区来进行对比，要搜寻整个文件系统呢。如果你的文件系统有100G以上，而且里面的档案数据又多，，而且在对Inernet提供服务的服务器主机上面，这样的检查真的会造成主机复原时间拉长，真是麻烦，这就有所谓的日志式文件系统的兴起了。

日志式文件系统(journaling filesystem)

为了避免上述提到文件系统不一致的情况发生，因此我们的前辈们想到了一个方式。如果我们在我们的filesystem当中画出一块区域，该区块专门记录写入或者修订档案时的步骤，那就可以简化一致性检查的步骤了？也就是：

1. 预备：当系统要写入一个档案时，会先在日志记录区块记录某个档案准备要写入的信息；
2. 实际写入：开始写入档案的权限与数据；开始更新metadata的数据；
3. 结束：完成数据与metadata更新后，在日志记录区块当中完成该档案的记录；

在这样的程序当中，万一数据的记录过程中发生了问题，那么我们的系统只要去检查日志记录区块，就可以知道那个档案发生了问题，针对该问题来做一致性检查即可，而不必针对整个filesystem去检查，这样就可以达到快速修复filesystem的能力了。这就是日志式档案最基础的功能了。

那么我们的ext2可以达到这样的功能吗？当然可以了啊！就透过ext3即可。ext3是ext2的升级版本，并且向下兼容ext2版本呢！所以罗，目前建议大家，可以直接使用ext3这个filesystem，如果你还记得superblock里面含有底下这样的信息：

看到了吧。透过inode8记录journal区块的block指向，而且具有128M的容量在处理日志呢！这样对所谓的日志式文件系统有没有比较有一点概念呢？

为什么要从ext2转化到ext3呢？有四个主要的理由：可利用性、数据完整性、速度以及易于装换、可利用性，他指出，这意味着从系统终止到快速恢复而不是持续的让e2fsck执行长时间的修复。ext3的日志条件可以避免数据毁损的可能。他也指出：除了写入若干数据超过一次时，ext3往往会快于ext2，因为ext3日志使硬盘读取头的移动更有效进行，然而或许决定因素还是在johnson先生的第四个理由中。