在jbd2源代码中,文件系统中的任何修改都被映射到一个handle_t
结构(每个进程)中,该结构稍后用于映射buffer_head
到transaction_t
该句柄将成为的一部分。
据我所知,当buffer_head
需要对给定进行修改时,调用do_get_write_access()
将把它映射buffer_head
到它所属的事务handle_t
。但是,当 thishandle_t
用于将 映射buffer_head
到 时transaction_t
,互易映射丢失了,也就是说,我无法追溯handle_t
thisbuffer_head
属于哪个。
问题是,在jbd2_journal_commit_transaction()
(提交功能中的提交阶段 2b)期间,我想找到一种方法来遍历这些buffer_heads
并能够对它们进行分类,如果它们与inode或metadata或inode 位图块相关,或数据位图块,例如。此外,在源代码的这一点上,buffer_heads
它们似乎是不透明的,它们只是被发送到存储中。
更新 1:
到目前为止,我在jbd2_journal_commit_transaction()
函数中尝试的是在提交阶段 2b中。
struct journal_head *jh;
...
jh = commit_transaction->t_buffers;
if(jh->b_jlist == BJ_Metadata) {
struct buffer_head *bh_p = NULL;
bh_p = jh2bh(jh);
if(!bh_p) printk(KERN_DEBUG "Null ptr in bh_p\n");
else {
struct address_space *as_p = NULL;
if((as_p = bh_p->b_assoc_map) == NULL)
printk(KERN_DEBUG "Null ptr in as_p\n");
else {
struct inode *i_p = NULL;
if(i_p) printk(KERN_DEBUG "Inode is %lu\n", i_p->i_ino);
}
}
}
它不起作用,它在 中给出 NULL ptr as_p
,也就是说,没有b_assoc_map
为此设置buffer_head
。但是,我不知道b_assoc_map
.
更新 2:
我正在尝试从handle_t
结构中获取信息ext4_mark_iloc_dirty
。handle_t->h_type
有我需要的信息。但是,当我尝试比较这个值时,NULL 指针会导致内核警告。我认为这个结构在每个进程中都是独一无二的,但似乎它有一些竞争条件,我还不清楚。