日志型文件系统的一点理解

本文基于个人笔记整理出来的，如有错误或不同见解，欢迎指正 journaling fs, 就是我们常说的： 日志型文件系统。比较典型的有： ext3, ext4, xfs等， 而ext2是不支持 日志的文件系统，该文件系统基本上已经不再使用；

简单介绍其实现原理： 在磁盘上有一块区域专门用来保存日志，叫做journaling 区域，在更新磁盘上特定的block之前，首先把要做的变更 记录到 journaling 区域，然后才去更新相应的block. 这样在系统崩溃的时候，可以通过journaling区域的信息，进行replay, 从而实现 恢复；

而在数据存储的时候，基本是分为两大块的：meta data 和 我们通常意义上所说的data（file data），meta data的重要性不在这里讨论，如果文件系统的meta data遭到破坏，那么文件系统数据将丢失； 而我们通常意义上的data(file data) ，如果发生丢失，并不会导致文件系统损坏，但是也会给我们的使用造成不小的麻烦；基于这一点，有两种journaling 的方式： logical journals 以及 physical journals. 二者的的区别如下： logical journals, 针对系统中的meta data做journaling, 如果operation 会导致 meta data发生变化，那么在meta data被更改之前，首先把即将apply的变化写入到 journaling 区域，成功写入journaling 区域后，才向 需要更改的block写入数据；这样，如果系统在更新meta data的时候发生crash, 重启之后，可以通过journaling区域的log 来replay 实现meta data的更新，确保 meta data的一致性；而如果 写入journaling 区域的时候发生了crash, 那么系统重启之后，原来的meta data 不会发生变化，因为 journaling log不完整，会被忽略，从而确保了文件系统的一致性， 总之呢，logical journals 就是确保 meta data不会存在只更新一部分的问题，或者成功更新 meta data, 或者 不更新 meta data. 因为meta data更新一部分，会导致文件系统的crash；

physical journals, 因为logical journals 仅仅确保了meta的更新可靠性，但是并不能确保 文件内容（file data）更新的可靠性，如果需要确保file data更新也是可靠的，那么需要 对每一个block 的变更都采用journal, 这样的话，就会明显导致系统性能的降低；所以使用不多，但是，如果数据的可靠性要求非常高，不容许任何错误，那么可以用性能来换取可靠性，采用physical journals；而为了提高对磁盘的访问性能，那么可以将journal 放置到external 存储设备上，从而降低因为journal 导致的IO性能下降；

在journaling file system 的wiki中，有这样一段话，描述了logical journaling 潜在的一种风险: A file system with a logical journal still recovers quickly after a crash, but may allow unjournaled file data and journaled metadata to fall out of sync with each other, causing data corruption. （使用logical类型的日志文件系统可以在crash之后快速的恢复， 但是，它可能导致没有journaled 的 文件数据 与 journaled的元数据 之间不同步，从而导致文件的数据损坏），说直白点就是： 文件系统fsck的结果是完好无误的，但是 文件的内容却corruption，或者有明显的文件丢失现象； 因为文件系统的完整性是依靠 meta data来保证的，而文件的内容却没有用journal 来保证crash时候的安全性；

采用journal 的文件系统在crash之后的恢复，为什么要比非 日志类型的文件系统恢复要快很多？ 因为日志型文件系统 是通过对journal的replay 来实现 meta data的完整性，而非日志型文件系统，则需要对每一个block都进行验证，所以数据恢复的时候会非常慢；

本文原创，转载请注明出处