I'm interested in how could one interpret the results of procfs-diskstats. It looks like an API, but I see no exhaustive explanation in Internet or man pages or Linux kernel Documentation.

There is a file with a very concise description:

The /proc/diskstats file displays the I/O statistics
of block devices. Each line contains the following 14

        ==  ===================================
         1  major number
         2  minor mumber
         3  device name
         4  reads completed successfully
         5  reads merged
         6  sectors read
         7  time spent reading (ms)
         8  writes completed
         9  writes merged
        10  sectors written
        11  time spent writing (ms)
        12  I/Os currently in progress
        13  time spent doing I/Os (ms)
        14  weighted time spent doing I/Os (ms)
        ==  ===================================

And also iostats.rst with a few words more. But it's still hard to tell what exactly means f.e. this metric:

13  time spent doing I/Os (ms)

From iostats.rst:

Field 10 -- # of milliseconds spent doing I/Os (unsigned int)
    This field increases so long as field 9 is nonzero.

    Since 5.0 this field counts jiffies when at least one request was
    started or completed. If request runs more than 2 jiffies then some
    I/O time might be not accounted in case of concurrent requests.

But when I watch this value per second on my 4-core CPU VM, this value growing(increments) by more than 100000 ms while copying f.e 4Gb file.
I can assume that HDD/SSD(SATA? Depends on bus?) could serve multiple CPU cores requests in parallel.
On 4-core CPU that means that 100000 ms increment in this counter represents HDD/SDD serving [at least 25 seconds on every CPU core's request] per second. Or 50 seconds on two cores (per second), or 100 second on 1 core (per second).

Common sense dictates that you cannot work more time per second than a second.

Related post: /proc/diskstats disk read time increasing more than second per second

UPD: Linux kernel 4.4.161, x86_64

  • I didn't manage to reproduce it. When dd from the disk from 2 process (on a 2 core processor), I get a maximum of 1004ms / 1s and I guess that my 1s loop made with a sleep(1) system call is not precise enough. From the Linux 4.9 source, I have a comment idencating that a care has been done to avoid more than 100% time reported : "Normally, that accounting is done on IO completion, but that can result in more than a second's worth of IO being accounted for within any one second, leading to >100% utilisation. To deal with that, [...]." Oct 11, 2021 at 16:54
  • Could you please name the kernel version (4.19, 5.0, 5.10 etc) and the architecture (PC, ARM etc.)?
    – Binarus
    Oct 13, 2021 at 18:12
  • @Binarus Updated the question.
    – z0lupka
    Oct 14, 2021 at 9:06
  • OK, thanks for the update. The kernel in the VM is quite old. You are right, the counter should not increase by more than 1000/sec. Guessing wildly, I'd say that the virtual disk driver in the guest has problems reporting those statistics correctly, or that the VM heavily suffers from a timing / lost interrupt problem. To analyze that, detailed knowledge would be required about how you have configured the VM and its virtual disk. It would be interesting what /proc/diskstats shows for the VM's virtual disk on the host (provided that it is not just a file).
    – Binarus
    Oct 14, 2021 at 14:45


Your Answer

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

Browse other questions tagged or ask your own question.