系统真忙碌～而且在对
Internet
提供服务的服务器主机上面，
这样的检查真的会造成主机复原时间
的拉长～真是麻烦～这也就造成后来所谓日志式文件系统的兴起了。
.
日志式文件系统
(Journaling filesystem)
为了避免上述提到的文件系统不一致的情况发生，因此我们的前辈们想到一个方式，
如果在我们的
filesystem
当中规划出一个区块，该区块专门在记录写入或修订文件时的步骤，
那不就可以简化一
致性检查的步骤了？也就是说：
1.
预备：当系统要写入一个文件时，会先在日志记录区块中纪录某个文件准备要写入的信息；
2.
实际写入：开始写入文件的权限与数据；开始更新
metadata
的数据；
3.
½束：完成数据与
metadata
的更新后，在日志记录区块当中完成该文件的纪录。
在这样的程序当中，万一数据的纪录过程当中发生了问题，那么我们的系统只要去检查日志记录区块，
就可以知道哪个文件发生了问题，针对该问题来做一致性的检查即可，而不必针对整块
filesystem
去
检查，
这样就可以达到快速修复
filesystem
的能力了！这就是日志式文件最基础的功能啰～
那么我们的
ext2
可达到这样的功能吗？当然可以啊！
就透过
ext3/ext4
即可！
ext3/ext4
是
ext2
的
升级版本，并且可向下兼容
ext2
版本呢！
所以啰，目前我们才½议大家，可以直½使用
ext4
这个
filesystem
啊！
如果你还记得
dumpe2fs
输出的讯息，可以发现
superblock
里面含有底下这样的信息：
Journal inode: 8
Journal backup: inode blocks
Journal features: (none)
Journal size: 32M
Journal length: 8192
Journal sequence: 0x00000001
看到了吧！透过
inode 8
号记录
journal
区块的
block
指向，而且具有
32MB
的容量在处理日志呢！
这样对于所谓的日志式文件系统有没有比½有概念一点呢？
^_^
。
7.1.6 Linux
文件系统的运作
我们现在知道了目录树与文件系统的关系了，但是由
第零章
的内容我们也知道，
所有的数据都得要
加载到内存后
CPU
才能够对该数据½行处理。想一想，如果你常常编辑一个好大的文件，
在编辑
的过程中又频繁的要系统来写入到磁盘中，由于磁盘写入的速度要比内存慢很多，
因此你会常常耗
在等待磁盘的写入
/
读取上。真没效率！
为了½决这个效率的问题，因此我们的
Linux
使用的方式是透过一个称为异步处理
(asynchronously)
的方式。所谓的异步处理是这样的：
当系统加载一个文件到内存后，如果该文件没有被更动过，则在内存区段的文件数据会被设定为干净
(clean)
的。
但如果内存中的文件数据被更改过了
(
例如你用
nano
去编辑过这个文件
)
，此时该内存中
的数据会被设定为脏的
(Dirty)
。此时所有的动作都还在内存中执行，并没有写入到磁盘中
！
系统会