I've been diving into the Linux kernel. and would like to trace an io request and find out exactly which process sent the current io request?

There is a structure named current which the kernel documentation says that represents currrent process.

However analysing the printk function in block/blk-core.c in function submit_bio it seems this is not the current process.

My printk is this:

printk(" Ata: in block/blk-core.c in submit_bio current task: %s pid:(%d): %s block %Lu on device %s (%u sectors)\n",
        current->comm, task_pid_nr(current),
            (rw & WRITE) ? "WRITE" : "READ",
            (unsigned long long)bio->bi_iter.bi_sector,
            bdevname(bio->bi_bdev, b),

However the output of it is not what I was expecting:

[Thu Dec 31 15:18:49 2015]  Ata: in block/blk-core.c in submit_bio current task: jbd2/sda1-8 pid:(494): WRITE block 54798672 on device sda1 (8 sectors)

the output says that current process is jbd2. According to this answer jbd2 is a function run by filesystem. In contrast with this my process was dd with pid : 2479.

How can I find exactly which process sent the current io request? something like iotop is doing.

  • I edited the English at some cost because it was barely intelligible. I suggest you could at least use a tool to check for misspelled words. The goal/method/question/point you are trying to meet/make is not entirely clear, is a tool for debugging enough, or are you asking for help with C code? – Rui F Ribeiro Jan 1 '16 at 11:32
  • @RuiFRibeiro thank you. no i want to know in which section og kernel code can i find current process – mR.aTA Jan 1 '16 at 18:17

A disk I/O request cannot in general be traced back to particular process. For example, if two processes access the same file at the same time (i.e. process 1 emits a request, and process 2 emits a request to load the same file before the request from process 1 is processed), the access would need to be traced back to both processes. With delayed writes, a write might be due to a process that no longer exists.

What iotop shows for each process is I/O at the file level, not at the disk level. If you were looking at a filesystem driver, current would designate the process that made the request. But you're looking at a block device driver; unless a process is accessing the disk directly (bypassing any filesystem), the I/O requests will come from an internal subsystem. This is the reason why iotop's per-process statistics don't match the total: the total is for the disk level.

Tracing back a disk I/O request to the process that caused it is impossible in general, as we saw above. I don't know if there's a debug mode that allows this tracing in the cases where it's possible; I'd expect it to be very resource-consuming.

  • thank you. but i didnt find how iotop or blktrace show io per process? – mR.aTA Jan 2 '16 at 9:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.