I'm researching linux kernel. Right now only for v3.10.61, it's just proof of concept.

I need to pass-through some hints to hardware about what kind of data in particular WRITE\READ operation. E.g. read inodes bitmap or write journal block or write user data or something else...

I'm assuming that at driver level I can reach bio struct from request_queue struct.

  1. I've created FS with this command: mkfs.ext4 -b 4096 -E lazy_itable_init=0,lazy_journal_init=0 -m 0 /dev/vda
  2. I've mounted it using this command: mount -o rw,nosuid,nodev,discard,noauto_da_alloc,data=ordered /dev/vda /mnt
  3. Added breakpoint in virtio_blk.c:377 and will skip writes related to journal
  4. Execute this dd command: dd if=/dev/urandom of=/mnt/foo2 bs=764 count=34
  5. Wait for breakpoint hit and will analyse backtrace under writeback subsystem.

Here is the backtrace:

#0  virtblk_request (q=0x87ab8000) at drivers/block/virtio_blk.c:377
#1  0x801c0b4c in __blk_run_queue_uncond (q=<optimized out>) at block/blk-core.c:312
#2  __blk_run_queue (q=0x87ab8000) at block/blk-core.c:329
#3  0x801c0c94 in queue_unplugged (q=0x87ab8000, depth=<optimized out>, from_schedule=<optimized out>) at block/blk-core.c:2920
#4  0x801c3a98 in blk_flush_plug_list (plug=<optimized out>, from_schedule=false) at block/blk-core.c:3030
#5  0x801c3d9c in blk_finish_plug (plug=0x8785fd8c) at block/blk-core.c:3037
#6  0x80091644 in generic_writepages (mapping=<optimized out>, wbc=0x8785fde0) at mm/page-writeback.c:1910
#7  0x80092a88 in do_writepages (mapping=<optimized out>, wbc=<optimized out>) at mm/page-writeback.c:1923
#8  0x800e7084 in __writeback_single_inode (inode=0x8740c290, wbc=0x8785fde0) at fs/fs-writeback.c:454
#9  0x800e7360 in writeback_sb_inodes (sb=0x87811000, wb=0x87ab81b0, work=0x8785fea4) at fs/fs-writeback.c:678
#10 0x800e757c in __writeback_inodes_wb (wb=0x1 <__vectors_start>, work=0x3ff) at fs/fs-writeback.c:723
#11 0x800e7760 in wb_writeback (wb=0x87ab81b0, work=0x8785fea4) at fs/fs-writeback.c:854
#12 0x800e838c in wb_check_old_data_flush (wb=<optimized out>) at fs/fs-writeback.c:969
#13 wb_do_writeback (wb=0x87ab81b0, force_wait=0) at fs/fs-writeback.c:1010
#14 0x800e848c in bdi_writeback_workfn (work=0x87ab81bc) at fs/fs-writeback.c:1040
#15 0x80039d34 in process_one_work (worker=0x87816180, work=0x87ab81bc) at kernel/workqueue.c:2189
#16 0x8003a40c in worker_thread (__worker=0x1 <__vectors_start>) at kernel/workqueue.c:2313
#17 0x8003f714 in kthread (_create=0x87845e20) at kernel/kthread.c:200
#18 0x8000dfb8 in ret_from_fork () at arch/arm/kernel/entry-common.S:91

Ok, here we go... At frame #8 we have not optimized inode variable for inspection:

p (*inode)->i_ino
$7 = 0

Can anyone explain me what this inode is about? Where can I found information regarding this kind of inodes? And how can I track the inode number for writeback oeprations?

1 Answer 1


Disclaimer: I have not tried any of these functions, and am working on the documentation and comments. My observations may be incorrect!

The only function that I can see that uses the i_ino value in fs/writeback.c is the internal function block_dump___mark_inode_dirty, which marks an inode as dirty if it's been hashed (and not already marked), and sets a timestamp (for future writeback operations.) The current list of inodes to be written back appears to be available as a list (struct bdi_writeback *wb) given to wb_writeback().

As you used data=ordered in your mount options, I don't believe that any data writebacks occur, so no inodes should be considered "dirty". According to the ext4 documentation:

data=ordered (*)

All data are forced directly out to the main file system prior to its metadata being committed to the journal.

Later, a description of how writeback works in ext4:

Data Mode

  • writeback mode

In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance.

  • ordered mode

In data=ordered mode, ext4 only officially journals metadata, but it logically groups metadata information related to data changes with the data blocks into a single unit called a transaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. In general, this mode performs slightly slower than writeback but significantly faster than journal mode.

If you're wanting to trace events on an ext4 partition, you might be interested in taking a look at how the ext4-JBD2 interface works in fs/ext4/ext4_jbd2.c and the trace interfaces available in include/trace/events/ext4.h.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .