上一小节谈到的仅是读取而已，那么如果是新建一个文件或目录时，我们的文件系统是如何处理的呢？ 这个时候就得要 block bitmap 及 inode bitmap 的帮忙了！假设我们想要新增一个文件，此时文件系统的行为是：
- 先确定使用者对于欲新增文件的目录是否具有 w 与 x 的权限，若有的话才能新增；
- 根据 inode bitmap 找到没有使用的 inode 号码，并将新文件的权限/属性写入；
- 根据 block bitmap 找到没有使用中的 block 号码，并将实际的数据写入 block 中，且更新 inode 的 block 指向数据；
- 将刚刚写入的 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 的内容与实际数据存放区产生不一致 （Inconsistent） 的情况了。
既然有不一致当然就得要克服！在早期的 Ext2 文件系统中，如果发生这个问题， 那么系统在重新开机的时候，就会借由 Superblock 当中记录的 valid bit （是否有挂载） 与 filesystem state （clean 与否） 等状态来判断是否强制进行数据一致性的检查！若有需要检查时则以e2fsck这支程序来进行的。
不过，这样的检查真的是很费时～因为要针对 metadata 区域与实际数据存放区来进行比对， 呵呵～得要搜寻整个 filesystem 呢～如果你的文件系统有 100GB 以上，而且里面的文件数量又多时， 哇！系统真忙碌～而且在对 Internet 提供服务的服务器主机上面， 这样的检查真的会造成主机复原时间的拉长～真是麻烦～这也就造成后来所谓日志式文件系统的兴起了。
- 日志式文件系统 （Journaling filesystem）
为了避免上述提到的文件系统不一致的情况发生，因此我们的前辈们想到一个方式， 如果在我们的 filesystem 当中规划出一个区块，该区块专门在记录写入或修订文件时的步骤， 那不就可以简化一致性检查的步骤了？也就是说：
- 预备：当系统要写入一个文件时，会先在日志记录区块中纪录某个文件准备要写入的信息；
- 实际写入：开始写入文件的权限与数据；开始更新 metadata 的数据；
- 结束：完成数据与 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 的容量在处理日志呢！ 这样对于所谓的日志式文件系统有没有比较有概念一点呢？^_^。