Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I want to measure some numbers related to disk io in a given timespan, programmatically. This means I don't want to spawn a process like iostat to get my numbers, by prefer to read something from proc or the like.

I need to know:

  • The number of blocks written to disk
  • The number of blocks read from disk
  • The number of blocks read from disk but found in the disk cache
  • The number of blocks about to be written to the disk, but not written yet, to know how much succeeding IO I might expect.

If I only get this information by disk or partition... this is even better, since I don't need to know how much information I read from proc.

If I additionally know how much time the process has waited for the IO to be done... even better.

Is this possible with some IO calls, or by reading and parsing the /proc files?

share|improve this question

1 Answer 1

up vote 5 down vote accepted

iostat reads from /proc/diskstats - I can't tell you which column corresponds to what though. That would take a bit of investigation. Additionally, if you'd like to get more info about a specific process, /proc/[processID] contains information pertaining to the process, such as io and mem

A line in the file looks like:

8    0 sda 1576985 366566 29817737 8671588 4847477 21489330 210704848 14116392 0 14120880 22772188

From /usr/src/linux-*/Documentation/iostats.txt:

Field  1 -- # of reads completed
    This is the total number of reads completed successfully.
Field  2 -- # of reads merged, field 6 -- # of writes merged
    Reads and writes which are adjacent to each other may be merged for
    efficiency.  Thus two 4K reads may become one 8K read before it is
    ultimately handed to the disk, and so it will be counted (and queued)
    as only one I/O.  This field lets you know how often this was done.
Field  3 -- # of sectors read
    This is the total number of sectors read successfully.
Field  4 -- # of milliseconds spent reading
    This is the total number of milliseconds spent by all reads (as
    measured from __make_request() to end_that_request_last()).
Field  5 -- # of writes completed
    This is the total number of writes completed successfully.
Field  6 -- # of writes merged
    See the description of field 2.
Field  7 -- # of sectors written
    This is the total number of sectors written successfully.
Field  8 -- # of milliseconds spent writing
    This is the total number of milliseconds spent by all writes (as
    measured from __make_request() to end_that_request_last()).
Field  9 -- # of I/Os currently in progress
    The only field that should go to zero. Incremented as requests are
    given to appropriate struct request_queue and decremented as they finish.
Field 10 -- # of milliseconds spent doing I/Os
    This field increases so long as field 9 is nonzero.
Field 11 -- weighted # of milliseconds spent doing I/Os
    This field is incremented at each I/O start, I/O completion, I/O
    merge, or read of these stats by the number of I/Os in progress
    (field 9) times the number of milliseconds spent doing I/O since the
    last update of this field.  This can provide an easy measure of both
    I/O completion time and the backlog that may be accumulating.
share|improve this answer
4  
See tipstricks.itmatrix.eu/?p=301 for a format description. –  uesp Mar 9 '11 at 17:30
1  
+1 Nice answer. Let me add the missing info :) –  Daniel Mar 9 '11 at 18:03
1  
Also check sar. –  coredump Mar 9 '11 at 18:46

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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