>>1.日志记录的是什么内容?
>>例如我要创建一个新文件,自然要分配新的索引节点和数据块，也就是要修改索引节点位图和块位图.
那么日志记录的是旧的块还是新的块,即记录修改前的位图还是修改后的位图?似乎是修改后的位图，即新块。
每次系统调用所执行的操作称为一个原子操作，多个原子操作可以合并到一个事务中,但一个事务能够接收的原子操作是有限的，例如更新1024个不同的块等。事务（称为running transaction)无法接收新的原子操作后，就会被强制提交(committing transaction),然后开始一个新的事务.
例如先写文件1，后在写文件二，它们的所有的修改位图、修改索引节点、修改组描述符、修改超级块、写数据操作(如果是journal模式)都可以合并到一个事务中，看成一个完整的操作。
日志记录的是由一个个完整的事务记录组成,每个事务记录结构为【1描述符块+若干元数据块】×N+1提交块。描述符块描述后面的的若干元数据块的原始信息，一个元数据块对应一个描述结构,描述结构给出该元数据块原始块号信息。xN的意思是一个描述符块最多只能存放一定量的描述符，元数据太多的话需要更多的描述符块.最后加上一个提交块，表明事务已经被完整地记录下来了，如果此时宕机的话就可以凭此还原元信息了.
事务记录的是本次事务中被修改过的元数据信息。
事务被写入日志后，原始信息怎么办呢，是不是立即更新到磁盘?
jbd的做法是无限期延迟，直到
1.相关的buffer_head被内存管理子系统或bdflush写入磁盘
2.日志记录已满，无法开始新的事务,系统强制回收check point事务,即flush所有的相关buffer_head到磁盘，释放check point事务.
>>2.多个原子操作组成/合并一个事务.一个journal是不是最多只有两个事务:一个正在运行的事务，一个正在提交的事务?
一个journal可以有三种状态的事务:
1.一个正在运行的事务，它可以接收新的原子操作
2.一个正在提交的事务，不能接收新的原子操作,准备将事务写入日志
3.若干个已提交日志(即已写入日志)，它们不能被立即释放，因为真实的写操作并未完成,因此事务处于check point状态,即由kjournald定时检查与该事务相关的buffer head是否已经被全部写入磁盘，如果是就释放该事务，相应的盘上事务记录被销毁，从而回收了日志空间.
>>3. 当一个事务超时时，就会被提交:先写日志记录到磁盘,然后写数据块到磁盘,最后销毁该日志记录.是这样的吗?
否。根据前面的说明可知，真实的写操作并没有立即执行,而是被延迟了，这样有助于提高系统性能.
阅读(1610) | 评论(0) | 转发(0) |
