find which process is sending the current io request in linux kernel

Question

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),
            count);

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.

Answer 1

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.