archive mirror
 help / color / mirror / Atom feed
From: Ilya Plenne <>
Subject: Why inode number is zero in writeback?
Date: Wed, 25 Jul 2018 15:01:54 +0300	[thread overview]
Message-ID: <> (raw)

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 just for now. For testing purposes I'm using
virtio_blk driver under qemu.

Here what I have done:

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 analyze 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
#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
#12 0x800e838c in wb_check_old_data_flush (wb=<optimized out>) at
#13 wb_do_writeback (wb=0x87ab81b0, force_wait=0) at fs/fs-writeback.c:1010
#14 0x800e848c in bdi_writeback_workfn (work=0x87ab81bc) at
#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
#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
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 operations?

PS. That's my first email in linux kernel mailing list... I'm sorry if
I have done something wrong

             reply	other threads:[~2018-07-25 13:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-25 12:01 Ilya Plenne [this message]
2018-07-25 16:56 ` Why inode number is zero in writeback? Andreas Dilger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).