[root@localhost ~]# debugfs -R "stat ./test" /dev/sda2

debugfs 1.39 (-May-)

Inode:    Type: directory    Mode:     Flags: 0x0   Generation:

User:      Group:      Size:

File ACL:     Directory ACL:

Links:    Blockcount:

Fragment:  Address:     Number:     Size:

ctime: 0x5768c427 -- Mon Jun  ::

atime: 0x57725a43 -- Tue Jun  ::

mtime: 0x5768c427 -- Mon Jun  ::

BLOCKS:

():

TOTAL: 

[root@localhost fs]# find / -name "*.c"   | xargs grep "void file_update_time" -rn

/usr/src/debug/kernel-2.6./linux-2.6..x86_64/fs/inode.c::void file_update_time(struct file *file)

/usr/src/kernels/linux-2.6./fs/inode.c::void file_update_time(struct file *file)

void file_update_time(struct file *file)

{

        struct inode *inode = file->f_path.dentry->d_inode;

        struct timespec now;

        enum { S_MTIME = , S_CTIME = , S_VERSION =  } sync_it = ;

        /* First try to exhaust all avenues to not sync */

        if (IS_NOCMTIME(inode))

                return;

        now = current_fs_time(inode->i_sb);

        if (!timespec_equal(&inode->i_mtime, &now))

                sync_it = S_MTIME;

        if (!timespec_equal(&inode->i_ctime, &now))

                sync_it |= S_CTIME;

        if (IS_I_VERSION(inode))

                sync_it |= S_VERSION;

        if (!sync_it)

                return;

        /* Finally allowed to write? Takes lock. */

        if (mnt_want_write_file(file))

                return;

        /* Only change inode inside the lock region */

        if (sync_it & S_VERSION)

                inode_inc_iversion(inode);

        if (sync_it & S_CTIME)

                inode->i_ctime = now;

        if (sync_it & S_MTIME)

                inode->i_mtime = now;

        mark_inode_dirty_sync(inode);

        mnt_drop_write(file->f_path.mnt);

}

EXPORT_SYMBOL(file_update_time);

[root@localhost jbd]# find / -name "*.c"   | xargs grep "int __log_start_commit" -rn

/usr/src/debug/kernel-2.6./linux-2.6..x86_64/fs/jbd/journal.c::int __log_start_commit(journal_t *journal, tid_t target)

/usr/src/kernels/linux-2.6./fs/jbd/journal.c::int __log_start_commit(journal_t *journal, tid_t target)

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 = target;

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

                          journal->j_commit_request,

                          journal->j_commit_sequence);

                wake_up(&journal->j_wait_commit);

                return ;

        }

        return ;

}

[root@localhost ~]# strace -f -F -T -r -p  -e trace=write,open,read,fsync

Process  attached with  threads - interrupt to quit

[pid  ]      0.000000 open("./test/h.frm", O_RDONLY) =  <0.000049>

[pid  ]      0.000492 read(, "\376\1\t\f\3\0\0\20\1\0\0000\0\0\20\0\5\0\0\0\0\0\0\0\0\0\0\2\10\0\10\0"..., ) =  <0.000062>

[pid  ]      0.000312 read(, "//\0\0 \0\0", ) =  <0.000019>

[pid  ]      0.000120 read(, "j\1\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., ) =  <0.000019>

[pid  ]      0.000154 read(, "\0\0\0\0\2\0\377\0", ) =  <0.000020>

[pid  ]      0.000299 read(, "5\0\2\1\2\24)                         "..., ) =  <0.000018>

[pid  ]      0.202203 fsync()      =  <0.003163>

[pid  ]      0.003619 write(, "P\262yW\2\1\0\0\0O\0\0\0'\1\0\0\10\0\1\0\0\0\0\0\0\0\4\0\0!\0"..., ) =  <0.000050>

[pid  ]      0.060908 fsync()      =  <0.003123>

[pid  ]      1.117089 fsync()      =  <0.005403>

[pid  ]      0.008428 fsync()      =  <0.000019>

[pid  ]      0.001892 fsync()      =  <0.000019>

[pid  ]      0.001509 fsync()     =  <0.002887>

[pid  ]      0.004133 fsync()      =  <0.000020>

[pid  ]      0.002916 fsync()      =  <0.000021>

[pid  ]      0.872229 fsync()      =  <0.005205>

[] EXT4 debugging support

[ ] JBD (ext3) debugging support

JDB调试支持

如果你正在使用Ext3日志文件系统（或者其他文件系统/设备可能会潜在使用JBD），这个选项可以让你在系统运行时开启调试输出，以便追踪任何错误。默认地这些调试输出是关闭的。

如果选Y，将可打开调试，使用echo N > /sys/kernel/debug/bd/jbd-debug，其中N是从1-5的数字，越高产生的调试输出越多。要再次关闭，使用echo  > /sys/kernel/debug/jbd/jbd-debug

[ ] JBD2 (ext4) debugging support

JDB2调试支持

如果你正在使用Ext4日志文件系统（或者其他文件系统/设备可能会潜在使用JBD2），这个选项可以让你在系统运行时开启调试输出，以便追踪任何错误。默认地这些调试输出是关闭的。

如果选Y，将可打开调试，使用echo N > /sys/kernel/debug/bd2/jbd2-debug，其中N是从1-5的数字，越高产生的调试输出越多。要再次关闭，使用echo  > /sys/kernel/debug/jbd2/jbd2-debug

进入此门的肯定都对journal block device有一定了解，需要对ext3文件系统有了解，多余的就不赘述。

为什么要设计JBD？

普通数据是存在硬盘上的，文件系统也是作为普通数据存在硬盘上，类似如果碰到突然断电的情况，硬盘就可能损坏，硬件损坏，还是要硬件设计保证，软件设计(JBD)就是解决软件错误，断电可能会导致软件错误，举个例子，文件系统相当于常用的压缩文件，普通数据则是其中一个txt中的文字，如果压缩到一半被杀掉，如果txt中的文字损坏，压缩文件仍能解压，只是txt内容不同而已，但如果压缩文件的结构被损坏，很可能解压不来任何文件。而JBD就是防止文件系统的结构数据（元数据）被损坏，它作为一个缓存块先缓存所有的元数据，如果磁盘数据异常后，就从缓存块中恢复。

JBD的具体工作流程：

如上图示，kernel正常读写磁盘，读磁盘直接获取，写磁盘则走两条路，每个IO群（即事务），先写到jbd里面，然后在写磁盘，如果写磁盘被中断，则从jbd恢复，如果jbd被中断，OK，没影响。jbd本身数据存储到磁盘的一个用户态不可见位置，即日志空间，日志空间本身是一个文件系统结构的存储空间，有超级块，组描述符，位图等，估计所有数据系统都是类似结构。

基本原理就不说了，下面就以ext3_mkdir为例，描述jbd工作机制。

首先通过ext3_journal_start获取原子操作handle，（原子操作即操作不可分割的，只有完成态和未开始状态，不会停留在中间态，和atomic_inc不同，atomic加减是限制多线程冲突，handle则是保证完整性），具体细节可以参考ext3_journal_start函数，我对此的理解是，ext3_journal_start对handle进行了初始化，获取当前journal空间的数据，比如，空闲字节的开始位置。

在后面ext3_new_inode函数中见handle传递进入，在ext3_new_inode中申请新inode，需要修改位图，当然还有超级块和组描述符等，下面截取位图的写入作为一个描述：

通过read_inode_bitmap获取位图数据bitmap_bh，用ext3_find_next_zero_bit算出空闲ino位置，用ext3_journal_get_write_access获取日志的写权限，更多的是将handle加入事务transaction管理，或者说将bitmap_bh加入到journal管理中，然后才开始进行具体的数据修改，也就是ext3_set_bit_atomic修改位图，修改完成使用ext3_journal_dirty_metadata标记为脏，即告诉journal本次handle操作结束，可以进行提交了。

ext3_new_inode下的组描述符也是类似，包括后面的目录项修改都是如此，也不赘述了。

需要提到的是，此处标记为脏的是元数据，非元数据使用ext3_journal_dirty_data函数，在ext3里面，如果发现当前数据是脏页，则直接进行刷新到磁盘，原因在注释中有描述。

至此，一个使用journal的标准写入过程结束，后续的就是提交了。

jbd有常驻线程kjournald负责提交transaction，kjournald线程每个ext系列的分区分一个，主要部分通过调用journal_commit_transaction完成。需要插播一下，如果编译内核的时候打开CONFIG_JBD_DEBUG或者CONFIG_JBD2_DEBUG开关，就可以根据jbd-debug跟踪jbd的执行过程，有更直接的感觉，在代码实现上就是jbd_debug函数。

具体流程我建议打开debug开关后，对比着看，具体代码不梳理了，直接上图：

jbd前面所有设计都是为了此时的提交，需要留意的是此时设计的普通数据在元数据前进行提交，来保证ordered执行顺序。另外在之前写文件流程中提到ext3_ordered_write_end，中调用walk_page_buffers中journal_dirty_data_fn标记普通数据为脏，会将已脏的数据先用sync_dirty_buffer刷磁盘一下，可以对比参看。

最后则是出问题之后日志进行恢复：

journal恢复是在mount挂载磁盘的时候，ext3_fill_super()一直调用到journal_recover，判断是否进行日志恢复也是如下判断。

即根据日志的超级块s_start参数是否为0判断。

整个恢复过程有3部分组成，都是调用do_one_pass，只是传参不同，第一步获取recovery_info信息，journal的起点和终点，journal是一个循环利用的环状存储介质。第二步获取REVOKE块，第三步PASS_REPLAY则根据描述符块将日志信息写到磁盘上。

另外提一下在工作中碰到一个案例：内核在写文件的时候发生了多次复位，根据内核黑匣子记录的信息，看到journal_bmap获取信息为0,日志被__journal_abort_soft中断 了，再写journal出现了panic。当时看以为bmap出现异常，中间读取有问题，后来把journal日志块倒出来看，对应的一个间接索引块里面全为0,在普通文件中是正常的，称为文件的洞，而日志则是格式化一开始就全分配了，而且顺序读取利用不应产生文件的洞。具体原因再也没找到，但是发现fsck不支持修改journal出现洞的问题，导致重复复位，后来找到社区高版本fsck比对一下，改了一个补丁，勉强算解决了问题。

以上都是开胃小菜，更多的请读代码，文章描述不细致的地方请参考jdb代码分析

—结束—

journal block device代码分析–OenHan

http://www.oenhan.com/ext3-jbd-journal