12 3 / 3 页下一页

journal block device (jbd)源代码分析——ext3日志机制分析 [复制链接]

panweiping

白手起家

论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2010-10-18 21:27 |只看该作者 |倒序浏览

本帖最后由 panweiping 于 2010-11-04 10:39 编辑

说明：只贴了前三章，后边太多了，感兴趣的看word或pdf吧。

一、前言——为什么要写这篇文章
在阅读ext3源代码的时候，才对什么是日志型文件系统有了更深刻的了解。内核里单独抽象了一个层次，称之为journal block device，简称为jbd，位于fs/jbd/目录，专门用于块设备的日志管理。细数其源代码，不到万行，但是相关的分析资料，少之又少，有两篇介绍jbd概念的，说得比较清楚，但是对着源代码看，仍然不得要领。于是痛下苦功，反复阅读代码，力求得到正解，今感觉略有小成，写出来供大家学习、批评指正，以期去伪存真。
本文分析的内核代码版本2.6.35，主要是fs/jbd和fs/ext3 两个目录。本文假设物理磁盘块大小512B，文件系统块大小1KB。文件系统组织物理磁盘块时是以格式化时设定的块大小为单位的，称谓文件系统块，下文有时会为了行文方便，称文件系统块为磁盘块。
读者在阅读本文前，最好对Linux VFS和ext2的相关概念比较熟悉，比如inode、磁盘块位图、三级磁盘块索引、块组等等。
“纸上得来终觉浅，绝知此事要躬行”。希望本文能够起到一个抛砖引玉的作用，要想获得更多的收获，还是得靠自己分析源代码。源码在前，了无秘密。
还有一点说明，我想将本文写成一篇技术文章，并不想写成论文，所以在参考文献的引用方面就不严格按照写论文的方式了，那样太费时间。我把主要的参考文献集中放在文章的末尾。建议读者可以先读读参考文献，再阅读本文。
限于水平有限，代码中有些逻辑我还是没有搞清楚的，有些英文的翻译也欠斟酌，文章排版、详略、章节布局等也有很多待改进的地方。希望大家提出宝贵修改建议。
作者：潘卫平邮件：panweiping3@163.com 博客：pwp.cublog.cn

二、提出问题——jbd要解决什么问题
本章主要是说明jbd要解决什么问题，或者说ext2的缺点在哪里，因为ext3与ext2的主要差别就在于ext3在ext2的基础上增加了日志功能。
假设你正在运行一个Linux系统，运行一个程序，在一个ext2分区上不断地读写磁盘文件。突然断电了，或者系统崩溃了，你的心里肯定会咯噔一下：“磁盘分区没坏吧？文件还完整么？”告诉你一个不幸的消息，文件可能不完整了，文件可能已经损坏了，甚至该分区不能再被挂载了。也就是说，意外的系统崩溃，可能会使ext2文件系统处于一个不一致的状态。
假设你的运气好一点，分区仍能被识别，但是重新挂载时，如果发现分区处于不一致状态，那么系统会自动调用fsck程序，尝试将文件系统恢复到一致的状态。那将是一个非常漫长的过程，并且随着磁盘容量的增大，花费的时间也越长，有时需要长达几个小时。这样会极大地影响系统的可用性。
总之，jbd的主要目的不是减少系统崩溃的概率，而是系统正常运行时，尽量使文件系统处于一个一致的状态，以及系统崩溃后，尽可能减少使文件系统重新处于一致性状态的时间。通过减少维护时间，增加系统的可用性。

三、解决问题——jbd是如何解决的
本章从总体上说明ext3采用什么方式解决第二章提出的问题。
提到一致性，大家可能会联想到数据库里面的事务的概念，因为事务有四个基本属性：
1) 原子性
事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。
2) 一致性
事务在完成时，必须使所有的数据都保持一致状态。
3) 隔离性
由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务识别数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是第二个事务修改它之后的状态，事务不会识别中间状态的数据。
4) 持久性
事务完成之后，它对于系统的影响是永久性的。该修改即使出现系统故障也将一直保持。

文件系统的开发者借用了数据库中事务的思想，将其应用于文件系统上，以期保证对文件系统操作的原子性、隔离性，尽量使文件系统处于一致性。
1.将对文件系统的某些操作抽象成原子操作
所谓原子操作，就是内部不再分割的操作，该操作要么完全完成，要么根本没有执行，不存在部分完成的状态。
那么，什么样的操作可以看成对文件系统的原子操作呢？往一个磁盘文件中追加写入1MB字节可以看成一个原子操作么？这个操作其实比较大，因为要写1MB的数据，要为文件分配1024个磁盘块，同时还要分配若干个索引块，也会涉及到很多的磁盘块位图、块组块的读写，非常复杂，时间也会比较长，中间出问题的机会就比较多，所以不适宜看做一个原子操作。
那么，什么样的操作可以看成对文件系统的原子操作呢？比如说为文件分配一个磁盘块，就看成一个原子操作就比较合适。分配一个磁盘块，可能需要修改一个inode块、一个磁盘块位图、最多三个间接索引块、块组块、超级块，一共最多7个磁盘块。将分配一个磁盘块看成一个原子操作，意味着上述修改7个磁盘块的操作要么都成功，要么都失败，不可能有第三种状态。
2.将若干个原子操作组合成一个事务
实现日志文件系统时，可以将一个原子操作就作为一个事务来处理，但是这样实现的效率比较低。于是ext3中将若干个原子操作组合成一个事务，对磁盘日志以事务为单位进行管理，以提高读写日志的效率。
3.在磁盘上单独划分一个日志空间
日志，在这里指的是磁盘上存储事务数据的那个地方，即若干磁盘块。它可以以一个单独的文件形式存在，也可以由文件系统预留一个inode和一些磁盘块，也可以是一个单独的磁盘分区。总之，就是磁盘上存储事务数据的那个地方。
提到日志时，可能还有另外一种含义，就是指它是一种机制，用于管理内存中的缓冲区、事务、磁盘日志数据读写等等所有这一切，统称为日志。读者注意根据上下文进行区分。
4.将内存中事务的数据写到日志中
文件系统可以选择定期（每隔5秒，或用户指定的时间间隔）或者立即将内存中的事务数据写到磁盘日志上，以备发生系统崩溃后可以利用日志中的数据恢复，重新使文件系统保持一致的状态。
这个间隔时间的选取，要注意性能的平衡。时间间隔越短，文件系统丢失的数据可能性就越少，一致性的时间点就越新，但是IO负担就越重，很可能就会影响系统的性能。反过来，时间间隔越大，文件系统丢失的数据可能就越多，一致性的时间点就越旧，但是IO负担就比较轻，不太会影响系统的性能。
5.崩溃吧，然后我们从日志中恢复数据
我们不期望崩溃，但是崩溃总会发生的，如果发生了，那就直面惨淡的人生吧！重新挂载分区时，会根据日志中记录的数据，逐一将其写回到磁盘原始位置上，以保证文件系统的一致性。起死回生的奇迹发生了。
jbd的思想就是原来内核读写磁盘的逻辑保持不变，但是对于影响文件系统一致性的数据块（即元数据块，第四章会详细解释），及时地写到磁盘上的日志空间中去。这样，即使系统崩溃了，也能从日志中恢复数据，确保文件系统的一致性。如错误！未找到引用源。，其中绿色的箭头表示正常的磁盘读写，紫色的箭头表示由jbd将元数据块额外写一份到磁盘日志中，红色箭头表示恢复时，由jbd将日志中的数据写回磁盘的原始位置。