本文基于个人笔记整理出来的，如有错误或不同见解，欢迎指正：

journaling fs, 就是我们常说的：日志型文件系统。比较典型的有： ext3, ext4, xfs等，而ext2是不支持日志的文件系统，该文件系统基本上已经不再使用；

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

我们知道，常见的文件/文件夹在磁盘上存储的时候，包含两部分信息：
meta 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的更新可靠性，但是并不能确保文件内容的可靠性，如果需要确保文件内容也是可靠的，那么需要对每一个block 的变更都采用journal, 这样的话，就会明显导致系统性能的降低；所以使用不多，但是，如果数据的可靠性要求非常高，不容许错误，那么可以用性能来换取可靠性，采用physical journals；为了提高对磁盘的访问性能，那么可以将journal 放置到external 存储设备上，从而降低因为journal 导致的IO性能下降；

在journaling file system 的wiki中，有这样一段话，描述了潜在的一种风险：
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都进行验证，所以数据恢复的时候会非常慢；

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