Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

[PATCH] block/stat.txt

I couldn't find any docs explaining the contents of /sys/block/<dev>/stat,
so I wrote up the following. I'm not completely sure it's accurate - Jens,
could you give a yea or nay on this?

In particular, the counts of read/write IOs and read/write sectors are
incremented in different places - it looks like they both increment as the
request is being finished, but I'm not completely sure of that.

Cc: Jens Axboe <axboe@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

authored by

Andy Isaacson and committed by
Linus Torvalds
37a32795 f7dd795e

+82
+82
Documentation/block/stat.txt
··· 1 + Block layer statistics in /sys/block/<dev>/stat 2 + =============================================== 3 + 4 + This file documents the contents of the /sys/block/<dev>/stat file. 5 + 6 + The stat file provides several statistics about the state of block 7 + device <dev>. 8 + 9 + Q. Why are there multiple statistics in a single file? Doesn't sysfs 10 + normally contain a single value per file? 11 + A. By having a single file, the kernel can guarantee that the statistics 12 + represent a consistent snapshot of the state of the device. If the 13 + statistics were exported as multiple files containing one statistic 14 + each, it would be impossible to guarantee that a set of readings 15 + represent a single point in time. 16 + 17 + The stat file consists of a single line of text containing 11 decimal 18 + values separated by whitespace. The fields are summarized in the 19 + following table, and described in more detail below. 20 + 21 + Name units description 22 + ---- ----- ----------- 23 + read I/Os requests number of read I/Os processed 24 + read merges requests number of read I/Os merged with in-queue I/O 25 + read sectors sectors number of sectors read 26 + read ticks milliseconds total wait time for read requests 27 + write I/Os requests number of write I/Os processed 28 + write merges requests number of write I/Os merged with in-queue I/O 29 + write sectors sectors number of sectors written 30 + write ticks milliseconds total wait time for write requests 31 + in_flight requests number of I/Os currently in flight 32 + io_ticks milliseconds total time this block device has been active 33 + time_in_queue milliseconds total wait time for all requests 34 + 35 + read I/Os, write I/Os 36 + ===================== 37 + 38 + These values increment when an I/O request completes. 39 + 40 + read merges, write merges 41 + ========================= 42 + 43 + These values increment when an I/O request is merged with an 44 + already-queued I/O request. 45 + 46 + read sectors, write sectors 47 + =========================== 48 + 49 + These values count the number of sectors read from or written to this 50 + block device. The "sectors" in question are the standard UNIX 512-byte 51 + sectors, not any device- or filesystem-specific block size. The 52 + counters are incremented when the I/O completes. 53 + 54 + read ticks, write ticks 55 + ======================= 56 + 57 + These values count the number of milliseconds that I/O requests have 58 + waited on this block device. If there are multiple I/O requests waiting, 59 + these values will increase at a rate greater than 1000/second; for 60 + example, if 60 read requests wait for an average of 30 ms, the read_ticks 61 + field will increase by 60*30 = 1800. 62 + 63 + in_flight 64 + ========= 65 + 66 + This value counts the number of I/O requests that have been issued to 67 + the device driver but have not yet completed. It does not include I/O 68 + requests that are in the queue but not yet issued to the device driver. 69 + 70 + io_ticks 71 + ======== 72 + 73 + This value counts the number of milliseconds during which the device has 74 + had I/O requests queued. 75 + 76 + time_in_queue 77 + ============= 78 + 79 + This value counts the number of milliseconds that I/O requests have waited 80 + on this block device. If there are multiple I/O requests waiting, this 81 + value will increase as the product of the number of milliseconds times the 82 + number of requests waiting (see "read ticks" above for an example).