荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: ykwch.bbs@bbs.cqupt.edu.cn (心蓝), 信区: Linux
标 题: About ext3 journaling 2
发信站: 幽幽黄桷兰 (Wed Dec 25 15:27:11 2002)
转信站: SZU!news.tiaozhan.com!news.happynet.org!CQUPT
实现·块缓存读写
Jbd中有一个专门的线程（执行的函数 fs/jbd/journal.c:
int kjournald(void*)）来根据一定的时间间隔去写将事务写入journal文件。
把事务写入，这显然不会是一个简单的操作，会要多部分数据，而文件系统可
能也要访问某一个块，所以同步问题又来了。在jbd中，有一个全局的
spinlock journal_datalist_lock。（这个锁本不该是全局的，它会把多个
ext3分区的块缓存都用一个锁保护起来，实现中仍这样做的原因可能是全局
锁实现起来更简单，而设计者没有时间修改）。
事务是在纪录对块的操作，不可避免的会出现在几个事务中访问同一个
块。所以，jbd不但要能从事务找到它涉及到的块缓存，同时也要能从块缓
存知道它在那个事务中被用到。那么要记录多少个从 "块缓存->事务" 的这
种关联？答案是一个。
如果两个事务都在写，逻辑上没问题，后一次将覆盖前一次的结果。但
是，运行时却要复杂很多。比如，事务31要写块7511，之后事务32也写7511，
该怎么办？设计者选择的是copy-on-write（所以"答案是一个":)，将缓存
复制一份，交给…写。
把"谁"给"谁"？设想这时候还有人需要读块7511，它应该读到那个数据呢？
应该是32将处理的那个缓存。所以，缓存复制后，新复制出来的一份交给事
务31处理，旧的（jbd注释中把这个叫做primary copy）交给事务32或是读者。
不过这部分的代码看起来比上面的要复杂得多。
实现·删除文件
按照设计者Dr. Stephen Tweedie的说法，"对于所有日志式文件系统的
设计者来说，删除文件是噩梦的来源"。
从一个例子来说。先删除目录 ./temp1（事务44），向文件./text按追
加模式写入数据（事务45）。具体点，删除目录导致释放目录使用的块7511；
追加数据时恰巧给./text 文件分配了块7511，然后写了一句话"nightmare"，
就在这时，宕机了。
还有其他事情碰巧也发生在一起了：journal层没能把上面这两个事务记
录在案。世界重新开始，自然目录./temp1保留了下来，而且内容却是
"nightmare"。
解决的方法…，我并没有在代码中找到，倒不是说一定就没实现。也许，
被移到ext3的实现代码中，由ext3尽可能保证不将刚释放掉的块立即再使用。
实现·on-disk结构
这里的信息全部来自于阅读代码，主要出现在函数：
fs/jbd/transaction.c: journal_commit_transaction 和
fs/jbd/recovery.c: journal_recovery 。
所以，即是第一手资料，又很可能会有遗漏。
每个事务在文件里包含了三个区域：块描述符区，Revoke区和Commit区。
每个区都有共同格式的标头。标头中包含常见的MagicNumber，区类型标示符，
这个区所属的事务的标示号。
描述符区：
在标头之后，是一系列的journal_block_tag_t结构，这些tag之后，是
同样数量的数据块，每个tag，记录了后面一个数据块实际的区块号。
Reovke区：
这个区的结构和实现过程倒是不难理解。Revoke，按照字典的意思，是
废弃，似乎和删除等有关系。不过从何它相关联的东西看，似乎它的作用很
少。
还是从假设说起。试想事务34记录了对块7511的写动作，事务35里记录
了"删除"7511的动作。让我们从两个面来看：在恢复过程中，上面这样的动
作显然只需要做事务35里的"删除"(实际上就是jbd什么也不做)；但是jbd在
记录时必须记下来，因为当还在34处时，它没办法预知未来要发生的事情。
在这算是一种优化吧，但仅此而已？
块结构：在标头后是多个被Revoke的块的标号。
Commit区：
这里的数据最简单，除了标头区内别的数据完全没用。这个区的逻辑意
思是：这个事务被完整地记录了。
--
爱在生活的点点滴滴
爱在生命的分分秒秒
我爱蓝水晶
※ 来源:·幽幽黄桷兰 bbs.cqupt.edu.cn·[FROM: BelovedGirl]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店