1

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.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
mR.aTA
  • 211
  • 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 01 '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 01 '16 at 18:17

1 Answers1

2

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.