projects / GitHub / mt8127 / android_kernel_alcatel_ttab.git / blame
| Commit | Line | Data |
|---|---|---|
| 37a32795 AI |
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). |