ext3_JBD_文档

Ext3文件系统

1 Ext3文件系统简介

Ext3一种日志式文件系统。日志文件系统会把系统对磁盘文件系统的更改首先一一记录在日志文件中，然后再更新到磁盘上。在由某种原因（例如down机等）而导致文件系统出现不一致的情况下，可以通过重放（replay）日志文件来恢复文件系统的一致性。

Ext3是直接从Ext2文件系统发展过来的，采用了Ext2文件系统的磁盘数据布局，实现了对Ext2的完全兼容。

根据写入日志的内容和数据刷新时间的不同，Ext3可支持三个不同的日志格式：Journal模式，ordered 模式和writeback模式。

1.1Ext3日志模式

首先介绍元数据的概念，在Ext2 和 Ext3中，有六种元数据，分别是：超级块，块组描述符，节点，间接块，数据位图。可见，元数据记录了数据的改变。

Ext3既可以只对元数据做日志，也可以同时对文件数据块做日志。具体来说，Ext3提供以下三种日志模式：

日志（Journal ）

文件系统所有数据和元数据的改变都记入日志。这种模式减少了丢失每个文件所作修改的机会，但是它需要很多额外的磁盘访问。例如，当一个新文件被创建时，它的所有数据块都必须复制一份作为日志记录。这是最安全和最慢的Ext3日志模式。

预定（Ordered ）

只有对文件系统元数据的改变才记入日志。然而，Ext3文件系统把元数据和相关的数据块进行分组，以便把元数据写入磁盘之前写入数据块。这样，就可以减少文件内数据损坏的机会；例如，确保增大文件的任何写访问都完全受日志的保护。这是缺省的Ext3 日志模式。

写回（Writeback ）

只有对文件系统元数据的改变才记入日志；这是在其他日志文件系统发现的方法，也是最快的模式

1.2日志块设备（JBD）

Ext3 文件系统本身不处理日志，而是利用日志块设备（Journaling Block Device）或叫JBD 的通用内核层。Ext3文件系统调用JDB例程以确保在系统万一出现故障时它的后续操作不会损坏磁盘数据结构。Ext3 与JDB 之间的交互本质上基于三个基本单元：日志记录，原子操作和事务。

日志记录本质上是文件系统将要发出的低级操作的描述。在某些日志文件系统中，日志记录只包括操作所修改的字节范围及字节在文件系统中的起始位置。然而，JDB 层使用的日

志记录由低级操作所修改的整个缓冲区组成。这种方式可能浪费很多日志空间（例如，当低级操作仅仅改变位图的一个位时），但是，它还是相当快的，因为JBD 层直接对缓冲区和缓冲区首部进行操作。

修改文件系统的任一系统调用都通常划分为操纵磁盘数据结构的一系列低级操作。如果这些低级操作还没有全部完成系统就意外宕机，就会损坏磁盘数据。为了防止数据损坏，

Ext3文件系统必须确保每个系统调用以原子的方式进行处理。原子操作是对磁盘数据结构的一组低级操作，这组低级操作对应一个单独的高级操作。

出于效率的原因，JBD 层对日志的处理采用分组的方法，即把属于几个原子操作处理的日志记录分组放在一个单独的事务中。此外，与一个处理相关的所有日志记录都必须包含在同一个事务中。一个事务的所有日志记录都存放在日志的连续块中。JBD层把每个事务作为整体来处理。例如，只有当包含在一个事务的日志记录中的所有数据提交给文件系统时才回收该事务所使用的块。

2 JBD层

2.1JBD层基本概念

Log record

记录文件系统中一个block的改动。记录格式为journal_block_tag_t结构，存储在日志文件.journal中的discriptor block。当JBD层把一个block写入磁盘时，给block对应的buffer head添加一个journal_head结构。

Atomic operation handle

一个system call对应的所有log record组织在一起，称为一个handle。为保证文件系统一致性，handle为原子操作，当恢复系统fsck时，要么执行一个handle中的所有log record操作，要么一个都不执行。

Transaction

JBD将多个handle组织成一个transaction，transaction中的所有log record存储在日志文件的连续的块中。当一个transaction中的所有log record被提交到磁盘上之后，这个transaction占用的block就可以被回收再利用了。

transaction的整个生命历程中的状态和完成的工作如下：

1)T_RUNNING:表示当前transaction正在运行，可以接收数据到各个链表。每当发起

一个写数据操作的时候，就会启动一个new handle, new handle会检查当前是否有running transaction,如果有，就向这个transaction里面提交数据。如果当前没有running transaction，就会创建一个新的transaction并置为running状态，向这个transaction提交数据。细节可以详见start_this_handle()函数

2)T_LOCKED:transaction的锁，很多时候会用到，比如commit的时候

3)T_RUNDOWN：

4)T_FLUSH:把ordered模式下的数据刷到硬盘上

5)T_COMMIT：写日志到硬盘。此时所有要写到日志的内容已经放到当前transaction

的t_buufer链表中了（三种日志模式下要写入的数据和元数据不一样，详见前面的分析，但是所有的内容都放入这个链表），扫描这个链表，把所有内容写入journal.

之后这个transaction会被加入到joural的checkpoint list,在合适的时候把数据或元数据写入硬盘。可见，checkpoint 就是把数据或元数据写入硬盘。

6)T_FINISHED：这时数据已经写入硬盘，transaction工作完毕，可以从日志中删除

了

2.2Jbd数据结构关系

journal_superblock_s

3 日志文件格式

日志文件.journal按block来纪录信息，这里有两个层面的含义：

1)日志文件记录的是文件系统中block的改动，而不是文件或者inode的改动；

2)日志文件本身以block为记录单位。

日志文件格式解析如下：

.journal日志文件的第一个block，也就是block 0存放的是journal super block，主要纪录了日志文件的block size大小、总block数量、第一个log块的块号、日志的第一个transaction ID号。

.journal日志文件中所有的block都以一个描述信息为开头，描述信息由journal_header_s结构表示，该结构信息如下：

typedef struct journal_header_s

{

__u32 h_magic;

__u32 h_blocktype;

__u32 h_sequence;

} journal_header_t;

其中，h_magic为固定值0xc03b3998U，用来判断这个block是否为合法块；h_sequence为该transaction的ID；h_blocktype分为5种类型：

#define JFS_DESCRIPTOR_BLOCK 1

#define JFS_COMMIT_BLOCK 2

#define JFS_SUPERBLOCK_V1 3

#define JFS_SUPERBLOCK_V2 4

#define JFS_REVOKE_BLOCK 5

3.1discriptor block

每个discriptor block的开头是journal_header_s结构，紧跟着journal_header_s 该结构之后是一个个journal_block_tag_t结构，该结构表示日志记录了文件系统中哪些block的副本，结构如下：

typedef struct journal_block_tag_s

{

__u32 t_blocknr; /* The on-disk block number */

__u32 t_flags; /* See below */

} journal_block_tag_t;

其中t_blocknr表示文件系统中的block号，t_flags标志为JFS_FLAG_LAST_TAG 时，表示该descriptor所有block tag结束。

3.2Commit block

Commit block只有一个journal_header_s结构表示。

3.3Revoke block

Revoke block的开头是一个journal_revoke_header_s结构，该结构之后跟随的是一个个4字节的整数，表示revoke的文件系统中的block号。其中r_count表示在该block中有多少字节是有效数据。

typedef struct journal_revoke_header_s

{

journal_header_t r_header;

int r_count; /* Count of bytes used in the block */

} journal_revoke_header_t;

4 ext3写数据

功能：

在ext2写数据的流程上增加对日志的操作，把数据和元数据放入transaction相关的链表.需要注意的是，写数据其实并没有把数据或元数据写入日志（这是commit的工作），更没有把数据或元数据写入硬盘（这时checkpoint的工作），它只是把数据和元数据放入transaction 相关的链表，以后会进一步处理。

4.1写数据流程图

ext3_journal_dirty_metadata

4.2三种模式处理流程：Journal

数据和元数据都是通过journal_dirty_metadata()函数放到t_buffer链表中去，先被写入日志，然后被放入commit_transaction->t_checkpoint_list中去，在check point 的时候被写入硬盘

Ordered：

元数据处理过程同Journal。数据被放到commit_transaction->t_sync_datalist,在处理t_buffer链表之前被写入硬盘，也就是说在元数据写入日志之前数据被写入硬盘

Writeback：

元数据处理过程同Journal。数据不做任何特殊处理，直接暴露在内存中，标为脏，通过内核的VM层写入磁盘

可见，Writeback和Ordered模式的区别是ordered 模式把数据放入了

commit_transaction->t_sync_datalist，在把元数据写入日志之前先把这些数据写入硬盘，从而保证了处理之间的先后关系，而Writeback没有，所以也就不会有这个保证。

4.3写数据流程详解

首先看函数调用关系：

ext3_file_write()

generic_file_aio_write

generic_file_aio_write_nolock

__generic_file_aio_write_nolock

generic_file_buffered_write

可以看出在generic_file_buffered_write函数以上，ext3与ext2函数的调用关系完全一致。也就是说，ext3的写数据流程完全是构建在ext2上的，只是在需要的时候增加对日志相关的操作，下面我们来看增加了那些操作：

下面我们根据上面的流程图来详细解释下每步做了什么：

1)ext3_prepare_write()首先会计算出对一个page的修改最多会修改到多少个文件系统

中的block

2)joural_start()中获取当前handle，并判断然后判断当前的journal-

>j_running_transaction是否存在，如果不存在则创建一个

3)写入数据是会到block bitmap、group descripor等元数据的改动，因此会调用

ext3_journal_dirty_metadata（）来处理相应的原数据，把元数据存储在当前transaction的t_buffer队列中。需要注意的是，日志的三种模式都在这里把元数据存在这个链表中，之后会对数据采用不用的处理方法。

4)之后会对不用的日志模式对数据采取不同的处理方法：

a)journal模式：调用ext3_journal_dirty_metadata()把数据也放入在当前

transaction的t_buffer队列中，以后会对数据和元数据采用相同的操作

b)ordered模式：调用ext3_journal_dirty_data()把数据放入当前transaction的

t_sync_datalist中。以后commit的时候会在处理元数据之前把这个链表的

数据写入硬盘

c)数据不做任何特殊处理，直接暴露在内存中，标为脏，通过内核的VM层写入

磁盘

4.4数据dirty位的转换过程（新增，针对数据）

4.4.1Journal模式：

4.4.1.1 Prepare write阶段：

ext3_prepare_write

|->block_prepare_write

|->__block_prepare_write 遍历此次write操作所涉及的所有bh, 查看uptodate情况，从磁盘映射需要涉及的块；map失败，走下面灰色部分

|->mark_buffer_dirty 把buffer_head标为dirty

|->_set_page_dirty_nobuffers 标记所在page为dirty，

|->radix_tree_tag_set 标志radixtree中对应page为dirty；

|->_mark_inode_dirty 如果page是文件的，标志文件的inode为dirty 如果是jounaled模式：

walk_page_buffers：遍历此次write操作所涉及的所有bh

|->do_journal_get_write_access 用该函数处理每个bh

|->ext3_journal_get_write_access

|->__ext3_journal_get_write_access

|->journal_get_write_access

|->journal_add_journal_head创建一个jh, 把其中的b_bh标志位指向bh，

bh的b_private设置为本jh, 设置bh的

BH_JBD标志位,表示该bh已经被纳入jbd体

系

|->do_get_write_access 把每个bh数据块加入active 事务的一个链表中，如果bh是脏的，那么有两种情况：buffer是non-journaled，并且正在进行写回，什么也不做；或者是journaled，如果该bh处于特定的队列中，调用jbd_unexpected_dirty_buffer；

|->jbd_unexpected_dirty_buffer:清除bh的dirty位，置JBD_Dirty位

注：符合条件的dirty的bh才会被置为jbddirty，条件是处于BJ_Metadata，BJ_Reserved，BJ_Shadow，BJ_Forget的任一队列中。一般新的bh加入时没有处于任何队列中，因此不会被置为jbddirty。

4.4.1.2 Commit write阶段：

ext3_journalled_commit_write

|->walk_page_buffers 遍历此次write操作所涉及的所有bh（一个page中）|->commit_write_fn 对每个bh调用该函数

|->ext3_journal_dirty_metadata

|->journal_dirty_metadata

|->set_buffer_jbddirty(bh) 置JBD_Dirty位

|->__journal_file_buffer 把jh放入事务的BJ_Metadata队列中|->ext3_mark_inode_dirty 如果需要，设置inode为dirty？？？

4.4.2Ordered模式：

4.4.2.1 Prepare write阶段：

ext3_prepare_write

4.4.2.2 Commit write阶段：

ext3_ordered_commit_write

|->walk_page_buffers() 遍历此次write操作所涉及的所有bh

|-> ext3_journal_dirty_data 每个bh用该函数进行处理

|->journal_dirty_data 不对dirty状态做任何调整，把jb放入BJ_SyncData队列；如果jh已经在一个事务中并且状态为BJ_SyncData，立即刷回磁盘|->journal_add_journal_head 每个bh包装成一个jh，把其中的b_bh

标志位指向bh，bh的b_private设置为本jh,

设置bh的BH_JBD标志位,表示该bh已经被

纳入jbd体系

|->generic_commit_write

|->__block_commit_write

|->set_buffer_uptodate(bh) & mark_buffer_dirty(bh);

|->mark_inode_dirty 如果需要，把inode置为dirty

4.4.3Writeback模式：

4.4.3.1 Prepare write阶段：

ext3_prepare_write

|->block_prepare_write

|->__block_prepare_write 遍历此次write操作所涉及的所有bh

4.4.3.2 Commit write阶段：

|->generic_commit_write

|->__block_commit_write

|->set_buffer_uptodate(bh) & mark_buffer_dirty(bh);

|->mark_inode_dirty 如果需要，把inode置为dirty

5 写日志和写数据到硬盘

5.1Kjournal线程

这个是ext3的守护线程，每5s自我启动一次，主要负责两件事：commit和checkpoint

5.1.1commit

功能：

改变当前transaction的state(不再是running了)，然后根据不同的模式做不同的操作：

a)ordered模式：把数据写到硬盘，把元数据写到日志，并提交到t_checkpoint_list

b)journalled模式：把数据和元数据写到日志，并提交到t_checkpoint_list

触发条件：

a)由kjournal唤醒，kjournal线程本身5s会自启动一次，或者由一个wake up

event启动

b)每次调用start_this_handle()的时候会检查当前transaction是否已经很大，使得

话就commit

c)ext3_sync_fs()会启动commit

d)当要以readonly模式mount一个fs的时候，journal_flush()会先启动commit

e)由于出错或者其他原因导致而要destroy，abort或者restart 当前journal的时

候，会先commit

细节解析：

上面那些不同的触发条件最后都会调用__log_start_commit()来修改journal->j_commit_request，然后唤醒kjournal线程调用journal_commit_transaction()函数来执行

commit的

5.1.1.1 数据结构以及其他

几个重要的list:

a)t_sync_datalist: 只保存ordered模式下数据.如果文件系统以"ordered"模式

mount上，那么这个函数会把所有数据刷到硬盘上，并等到所有数据写完

b)t_buffers: 如果是journalled模式，数据和元数据都是存在这个list中的。而在

ordered模式下，这个list只保存元数据,因为journal_commit_transaction()里

面先处理commit_transaction->t_sync_datalist，并等待处理完毕，然后才处理commit_transaction->t_buffers，这样就保证了ordered模式下数据被先写回磁盘，然后metadata才写入日志

c)t_checkpoint_list：保存需要被写到磁盘上的数据。t_buffers中的内容被复制成

两份，一份被提交到日志，然后释放；一份被提交到这个list里面，在check point

的时候写到硬盘

d)t_forget顾名思义，遗忘队列，当队列提交以后这个队列中的bh是不用cp的，所

以在transaction生命中会把一些bh放到这个队列，然后结束之前会根据这些bh

的状态来处理

commit过程中transaction的状态变化：

transaction->t_state 从T_RUNNING ，T_FLUSH ，T_COMMIT ，之后会分两种情况，一种情况t_checkpoint_list为空，说明数据已经被写到硬盘上了，说明transaction的整个生命历程已经结束了，状态变为T_FINISHED；另一种情况t_checkpoint_list不为空，当前commit_transaction就被挂到了journal->j_checkpoint_transactions中去，等待check point，然后数据都刷到硬盘上了，状态

就变为T_FINISHED

t_buffer

5.1.1.2 commit工作流程

commit的所有流程都集中在journal_commit_transaction()函数里面，具体流程如下：

1)锁定当前transaction and 并等待所有的updates完成.比如前一个journal_flush对

journal sb 的影响，还有所有的commit_transaction->t_updates

2)丢弃所有剩余的BJ_Reserved buffers（t_reserved_list :Doubly-linked circular

list of all buffers reserved but not yet modified by this transaction）

3)清空journal->j_checkpoint_transactions->t_checkpoint_list，通过丢弃所有的

written-back buffers来释放一些内存

__journal_clean_checkpoint_list(journal);

4)切换到新的revoke table(j_revoke_table: maintains the list of revoked blocks

in the current transaction)，在当前jounal的两个revoke table 中选择空余的那个，因为不想等到有内容的那个revoke table被写完。然后会初始化这个revoke table，也就是说，它现在是空的

5)写revoke block

journal_write_revoke_records(journal, commit_transaction);

6)扫描commit_transaction->t_sync_datalist，把数据写回硬盘（这个链表存储的数

据是oredered模式下的数据），具体细节如下：

a)把t_sync_datalist 中的所有buffers写到硬盘。

b)等待所有已提交的IO (即t_locked_list)完成

c)写入revoke块

7)扫描t_buffers list，把数据和元数据做两份，一份写到日志，另一份提交到t_forget。

写日志的时候先申请一个descriptor块，然后做一条记录，写一块，做一个记录写一块，一个descriptor块满了就再申请，再写

8)wait for the IO so far to complete. 这里分别等待t_iobuf_list（存放t_buffer 中

的要写到日志里面的块）和t_log_list（存放descriptor块）

9)向日志中写入 commit record

10)扫描t_forget队列，若其中的bh在某个transaction的checpoint队列里面，移除

它，若bh状态为jbddirty,把它加入到当前commit_transaction的checpoint队列5.1.2checkpoint

功能：

把journal的所有的等待checkpoint的transactions的数据或元数据写入硬盘

触发条件：

a)每次调用start_this_handle()的时候会检查journal是否有足够空间,没有就会

checkpoint

b)当要以readonly模式mount一个fs的时候，journal_flush()会做checkpoint

c)由于出错而要destroy 当前journal的时候，会先checkpoint

checpoint工作流程：

checkpoint的工作很简单，它会扫描journal的checkpoint transactions链表，把每个transaction的t_checkpoint_list的数据刷回硬盘，并更新superblock中的内容。

函数详解见函数解析部分。

6 利用日志恢复数据

触发条件：

1)每次load journal(journal_load()函数)时会恢复数据

2)fsck

6.1重要的数据结构：

j_revoke：

The revoke table，保存当前transaction的revoked blocks，组织结构图如下，其中一个块是否在revoke talbe中，是由blocknr决定的；另外，每个journal有两个

jbd_revoke_table_s结构，至于每个transaction具体用那个有一个hash算法

JFS_REVOKE_BLOCK

除了一个块头之外，所有的内容都是一个个4字节大小的blocknr，recover数据的时候把这些blocknr加入revoked list,恢复的时候不恢复这些块。

每个commit transation 都有REVOKE_BLOCK，这些数据不用恢复，说明以后的transaction会更新它

revoke table的生命流程：

journal_commit_transaction()先切换了revoke table, 然后初始化，所以对每个commit来说,最开始revoke table都是空的。

6.2数据恢复流程

数据恢复的核心函数是journal_recover()和do_one_pass()，恢复过程分三步，功能分别如下：

1)第一次定位log的end，从前向后扫描journal所有块，不做任何动作，直到最后一个

块

2)第二次搜集revoke list，从前向后扫描journal所有块，处理每个REVOKE_BLOCK，

把REVOKE_BLOCK中标明的块加入到revoke list 中去

3)第三次恢复un-revoked blocks数据，描整个journal，处理每个descriptor块。读descriptor块的每条记

录，然后检查该块是否在revoked list中，如果不在，就把journal的数据读进来，置为dirty，然后扔给vm就行了

7 函数解析

7.1ext3写数据相关

7.1.1ext3_creat_journal()

函数流程如下：

1)获取日志文件inode信息，创建journal_t结构，并根据inode信息设置

journal_t结构。

journal->j_dev = journal->j_fs_dev = inode->i_sb->s_bdev;

journal->j_inode = inode;

journal->j_maxlen = inode->i_size >> inode->i_sb-

>s_blocksize_bits;

journal->j_blocksize = inode->i_sb->s_blocksize;

2)读入journal日志文件的超级块，也就是.journal文件的block 0，存放在一个bh

中。

journal->j_sb_buffer = bh;

journal->j_superblock = (journal_superblock_t *)bh->b_data;

3)将journal_t结构和文件系统super block关联。

journal->j_private = sb;

4)调用journal_creat()将journal日志文件清空

5)调用journal_reset()将journal super block更新

6)调用journal_start_thread()启动journal守护线程kjournald

7.1.2ext3_writepage_trans_blocks()

计算对一个page的修改最多会修改到多少个文件系统中的block，对4k block size 并且日志模式为writeback的文件系统来说，计算方法为：2*(1+3)+2=10。这个数据用来判断日志文件中是否有足够的空间来存储这次handle。

7.1.3journal_start()

ext3_journal_start()

->journal_start()

首先获取当前handle，当前handle保存在current->journal_info中，如果当前handle不存在，则创建一个新的handle，初始化handle的成员变量，并将handle赋值给current->journal_info。

然后判断当前的journal->j_running_transaction是否存在，如果不存在则创建一个。初始化transaction的成员变量。并为当前transaction添加一个定时器，定时器的周期为5秒，定时时间到了之后唤醒kjournal线程。

transaction->t_journal = journal;

transaction->t_state = T_RUNNING;

transaction->t_tid = journal->j_transaction_sequence++;

transaction->t_expires = jiffies + journal->j_commit_interval;

INIT_LIST_HEAD(&transaction->t_jcb);

spin_lock_init(&transaction->t_handle_lock);

spin_lock_init(&transaction->t_jcb_lock);

/* Set up the commit timer for the new transaction. */

journal->j_commit_timer->expires = transaction->t_expires;

add_timer(journal->j_commit_timer);

J_ASSERT(journal->j_running_transaction == NULL);

journal->j_running_transaction = transaction;

判断journal日志中的空闲block是否满足要求，如果不满足，调用__log_wait_for_space()启动checkpoint，以便回收更多的空闲块。

7.1.4ext3_new_block()

block_prepare_write()

->ext3_get_block()

ext3_get_block_handle()

ext3_alloc_branch ()

ext3_alloc_block()

ext3_new_block()

分配新的block会涉及到block bitmap、group descripor等的改动，因此会调用ext3_journal_dirty_metadata（）来处理相应的原数据。journal_dirty_metadata()首先将bh设置为jbddirty，然后调用__journal_file_buffer()将bh的dirty和jdbdirty标志清除，最后将jh链入当前transaction的transaction->t_buffers链表，并设置bh的jbddirty标志位。

7.1.5walk_page_buffers ()

对一个page内的所有buffer,循环调用journal_get_write_access()

7.1.6ext3_journal_get_create_access()

7.1.7journal_get_write_access()

a)如果bh是脏的，那么有两种情况：buffer是non-journaled，并且进行合法的写

回；或者是journaled，这种情况下清除bh的dirty位，置JBD_Dirty位，也就是说，该bh由JBD接管了

b)如果该buffer已经属于当前transaction,那么什么都不用做；如果该buffer属于以

前的某transaction，并且该transaction将要被commit，那么我们就不能覆盖

它，将该buffer拷到jh->b_frozen_data,以此来保护它

7.1.8journal_dirty_metadata()

//将之加入t_buffer list

→__journal_file_buffer()

7.1.9journal_dirty_data()

// 将之加入 transaction->t_sync_datalist

→__journal_file_buffer()

7.1.10g eneric_commit_write()

把相应的bh标记为脏，由VM层写入硬盘

7.1.11j ournal_stop()

这个函数动作很少，只是修改了handle所属transaction的transaction->t_outstanding_credits，唤醒transaction->t_updates和journal->j_wait_transaction_locked队列；并且如果需要的话唤醒一个commit，如果当前动作要求同步的话，还要等待commit结束

7.1.12j ournal_file_buffer()

把 bh插入到相应的列表，另外，bh的dirty标记会变为jbddirty

如果原来是dirty或者jbddirty，bh的标志位置为jbddirty

否则不改变标志位

7.1.13j ournal_unfile_buffer()

把 bh从相应的列表中移除，另外，bh的jbddirty标记会变为dirty

7.1.14s tart_this_handle()

每当发起一个写数据操作的时候，就会启动一个new handle, new handle会检查当前是否有running transaction,如果有，就向这个transaction里面提交数据。如果当前没有running transaction，就会创建一个新的transaction并置为running状态，向这个transaction提交数据。

7.1.15e xt3_creat_journal()

函数作用：

读入日志文件的相关信息。

函数流程：

1)首先获取日志文件inode信息，然后创建journal_t结构，并根据inode信息设置

journal_t结构：

journal->j_dev = journal->j_fs_dev = inode->i_sb->s_bdev;

journal->j_inode = inode;

journal->j_maxlen = inode->i_size >> inode->i_sb->s_blocksize_bits;

journal->j_blocksize = inode->i_sb->s_blocksize;

2)然后读入journal日志文件的超级块，也就是.journal文件的block 0，存放在一个

bh中。

journal->j_sb_buffer = bh;

journal->j_superblock = (journal_superblock_t *)bh->b_data;

3)将journal_t结构和文件系统super block关联。

journal->j_private = sb;

4)然后调用journal_creat()将journal日志文件清空

5)调用journal_reset()将journal super block更新

6)调用journal_start_thread()启动journal守护线程kjournald。

7.1.16j ournal_add_journal_head

创建一个jh, 把其中的b_bh标志位指向bh，把bh的b_private设置为本jh

设置bh的BH_JBD标志位

bh引用计数加1，jh的引用计数加1

返回bh->b_private

7.2commit

7.2.1__log_start_commit()

函数功能：

所有想要主动发起commit的函数都会调用这个函数，这个函数的主要作用是修改

journal->j_commit_request(使之不等于j_commit_sequence，kjournal线程会根据这个条件开始commit. ) 然后唤醒commit队列wake_up(&journal->j_wait_commit)

int __log_start_commit(journal_t *journal, tid_t target)

{

/*

* Are we already doing a recent enough commit?

*/

if (!tid_geq(journal->j_commit_request, target)) {

/*

* We want a new commit: OK, mark the request and wakup the

* commit thread. We do _not_ do the commit ourselves.

*/

//修改journal->j_commit_request

journal->j_commit_request = target;

jbd_debug(1, "JBD: requesting commit %d/%d\n",

journal->j_commit_request,

journal->j_commit_sequence);

//wake up等待队列，这里是kjournal函数

wake_up(&journal->j_wait_commit);

return 1;

}

return 0;

}

7.2.2kjournald()

int kjournald(void *arg)

{

journal_t *journal = (journal_t *) arg;

transaction_t *transaction;

struct timer_list timer;

current_journal = journal;

daemonize("kjournald");

/* Set up an interval timer which can be used to trigger a

commit wakeup after the commit interval expires */

//这里初始化了一个定时器

init_timer(&timer);

timer.data = (unsigned long) current;

timer.function = commit_timeout;

journal->j_commit_timer = &timer;

/* Record that the journal thread is running */

journal->j_task = current;

wake_up(&journal->j_wait_done_commit);

printk(KERN_INFO "kjournald starting. Commit interval %ld seconds\n",

journal->j_commit_interval / HZ);

/*

* And now, wait forever for commit wakeup events.

*/

spin_lock(&journal->j_state_lock);

loop:

jbd_debug(1, "commit_sequence=%d, commit_request=%d\n",

journal->j_commit_sequence, journal->j_commit_request);

//不断检查看二者是否相等，不等则说明有函数主动修改了j_commit_request，而发起了commit if (journal->j_commit_sequence != journal->j_commit_request)

{

jbd_debug(1, "OK, requests differ\n");

spin_unlock(&journal->j_state_lock);

del_timer_sync(journal->j_commit_timer);

journal_commit_transaction(journal);

spin_lock(&journal->j_state_lock);

goto end_loop;

}

wake_up(&journal->j_wait_done_commit);

if (current->flags & PF_FREEZE)

{

/*

* The simpler the better. Flushing journal isn't a

* good idea, because that depends on threads that may

* be already stopped.

*/

jbd_debug(1, "Now suspending kjournald\n");

spin_unlock(&journal->j_state_lock);

refrigerator(PF_FREEZE);

spin_lock(&journal->j_state_lock);

} else

{

/*

* We assume on resume that commits are already there,

* so we don't sleep

*/

DEFINE_WAIT(wait);

int should_sleep = 1;

//将当前函数加入&journal->j_wait_commit等待队列

prepare_to_wait(&journal->j_wait_commit, &wait,

TASK_INTERRUPTIBLE);

if (journal->j_commit_sequence != journal->j_commit_request)

should_sleep = 0;

transaction = journal->j_running_transaction;

if (transaction && time_after_eq(jiffies,

transaction->t_expires))

should_sleep = 0;

if (should_sleep) {

spin_unlock(&journal->j_state_lock);

schedule();

spin_lock(&journal->j_state_lock);

}

finish_wait(&journal->j_wait_commit, &wait);

}

jbd_debug(1, "kjournald wakes\n");

/*

* Were we woken up by a commit wakeup event?

*/

transaction = journal->j_running_transaction;

// jiffies>= transaction->t_expires，即当前transaction运行超过5s,修改journal->j_commit_request，下一次循环的时候就会调用commit函数

if (transaction && time_after_eq(jiffies, transaction->t_expires)) {

journal->j_commit_request = transaction->t_tid;

jbd_debug(1, "woke because of timeout\n");

}

end_loop:

if (!(journal->j_flags & JFS_UNMOUNT))

goto loop;

spin_unlock(&journal->j_state_lock);

del_timer_sync(journal->j_commit_timer);

journal->j_task = NULL;

wake_up(&journal->j_wait_done_commit);

jbd_debug(1, "Journal thread exiting.\n");

return 0;

}

7.2.3journal_commit_transaction()

函数功能：

改变当前transaction的state(不再是running了)，然后根据不同的模式做不同的操作：

c)ordered模式：把数据写到硬盘，把元数据写到日志，并提交到t_checkpoint_list

d)journalled模式：把数据和元数据写到日志，并提交到t_checkpoint_list

函数流程：

1)锁定当前transaction and 并等待所有的updates完成.比如前一个journal_flush对

journal sb 的影响，还有所有的commit_transaction->t_updates

2)丢弃所有剩余的BJ_Reserved buffers（t_reserved_list :Doubly-linked circular

list of all buffers reserved but not yet modified by this transaction）

3)清空journal->j_checkpoint_transactions->t_checkpoint_list，通过丢弃所有的

written-back buffers来释放一些内存

__journal_clean_checkpoint_list(journal);

4)切换到新的revoke table(j_revoke_table: maintains the list of revoked blocks

in the current transaction)，在当前jounal的两个revoke table 中选择空余的那个，因为不想等到有内容的那个revoke table被写完。然后会初始化这个revoke table，也就是说，它现在是空的

5)写revoke block

journal_write_revoke_records(journal, commit_transaction);

6)如果是oredered模式，把数据写回硬盘

d)把t_sync_datalist 中的所有buffers写到硬盘。

while (commit_transaction->t_sync_datalist) //扫描t_sync_datalist

{

if (buffer_locked(bh)) //说明io已经提交，但是没完成

__journal_file_buffer();

把它从t_sync_datalist中移除，加入到transaction->t_locked_list

（t_locked_list ：Doubly-linked circular list of all buffers under writeout

during commit）。下面会等待这个链表IO完毕

else

if (buffer_dirty(bh)) //对于所有dirty的bh