Chinaunix首页 | 论坛 | 博客
  • 博客访问: 372426
  • 博文数量: 64
  • 博客积分: 2975
  • 博客等级: 少校
  • 技术积分: 831
  • 用 户 组: 普通用户
  • 注册时间: 2007-01-14 10:59
文章存档

2014年(2)

2012年(7)

2010年(40)

2009年(5)

2008年(8)

2007年(2)

分类:

2007-05-14 11:11:29

>>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. 当一个事务超时时,就会被提交:先写日志记录到磁盘,然后写数据块到磁盘,最后销毁该日志记录.是这样的吗?
否。根据前面的说明可知,真实的写操作并没有立即执行,而是被延迟了,这样有助于提高系统性能.

 
阅读(1621) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~