blob: 4873c759d535a7549d5eecf62a7125b29d6c2dea [file] [log] [blame]
Jerome Marchand0e53c2b2008-02-08 11:10:56 +01001What: /sys/block/<disk>/stat
2Date: February 2008
3Contact: Jerome Marchand <jmarchan@redhat.com>
4Description:
5 The /sys/block/<disk>/stat files displays the I/O
6 statistics of disk <disk>. They contain 11 fields:
André Goddard Rosaaf901ca2009-11-14 13:09:05 -02007 1 - reads completed successfully
Jerome Marchand0e53c2b2008-02-08 11:10:56 +01008 2 - reads merged
9 3 - sectors read
10 4 - time spent reading (ms)
11 5 - writes completed
12 6 - writes merged
13 7 - sectors written
14 8 - time spent writing (ms)
15 9 - I/Os currently in progress
16 10 - time spent doing I/Os (ms)
17 11 - weighted time spent doing I/Os (ms)
18 For more details refer Documentation/iostats.txt
19
20
21What: /sys/block/<disk>/<part>/stat
22Date: February 2008
23Contact: Jerome Marchand <jmarchan@redhat.com>
24Description:
25 The /sys/block/<disk>/<part>/stat files display the
26 I/O statistics of partition <part>. The format is the
27 same as the above-written /sys/block/<disk>/stat
28 format.
Martin K. Petersenc1c72b52008-06-17 18:59:57 +020029
30
31What: /sys/block/<disk>/integrity/format
32Date: June 2008
33Contact: Martin K. Petersen <martin.petersen@oracle.com>
34Description:
35 Metadata format for integrity capable block device.
36 E.g. T10-DIF-TYPE1-CRC.
37
38
39What: /sys/block/<disk>/integrity/read_verify
40Date: June 2008
41Contact: Martin K. Petersen <martin.petersen@oracle.com>
42Description:
43 Indicates whether the block layer should verify the
44 integrity of read requests serviced by devices that
45 support sending integrity metadata.
46
47
48What: /sys/block/<disk>/integrity/tag_size
49Date: June 2008
50Contact: Martin K. Petersen <martin.petersen@oracle.com>
51Description:
52 Number of bytes of integrity tag space available per
53 512 bytes of data.
54
55
56What: /sys/block/<disk>/integrity/write_generate
57Date: June 2008
58Contact: Martin K. Petersen <martin.petersen@oracle.com>
59Description:
60 Indicates whether the block layer should automatically
61 generate checksums for write requests bound for
62 devices that support receiving integrity metadata.
Martin K. Petersenc72758f2009-05-22 17:17:53 -040063
64What: /sys/block/<disk>/alignment_offset
65Date: April 2009
66Contact: Martin K. Petersen <martin.petersen@oracle.com>
67Description:
68 Storage devices may report a physical block size that is
69 bigger than the logical block size (for instance a drive
70 with 4KB physical sectors exposing 512-byte logical
71 blocks to the operating system). This parameter
72 indicates how many bytes the beginning of the device is
73 offset from the disk's natural alignment.
74
75What: /sys/block/<disk>/<partition>/alignment_offset
76Date: April 2009
77Contact: Martin K. Petersen <martin.petersen@oracle.com>
78Description:
79 Storage devices may report a physical block size that is
80 bigger than the logical block size (for instance a drive
81 with 4KB physical sectors exposing 512-byte logical
82 blocks to the operating system). This parameter
83 indicates how many bytes the beginning of the partition
84 is offset from the disk's natural alignment.
85
86What: /sys/block/<disk>/queue/logical_block_size
87Date: May 2009
88Contact: Martin K. Petersen <martin.petersen@oracle.com>
89Description:
90 This is the smallest unit the storage device can
91 address. It is typically 512 bytes.
92
93What: /sys/block/<disk>/queue/physical_block_size
94Date: May 2009
95Contact: Martin K. Petersen <martin.petersen@oracle.com>
96Description:
Martin K. Petersen7e5f5fb2009-07-31 11:49:13 -040097 This is the smallest unit a physical storage device can
98 write atomically. It is usually the same as the logical
99 block size but may be bigger. One example is SATA
100 drives with 4KB sectors that expose a 512-byte logical
101 block size to the operating system. For stacked block
102 devices the physical_block_size variable contains the
103 maximum physical_block_size of the component devices.
Martin K. Petersenc72758f2009-05-22 17:17:53 -0400104
105What: /sys/block/<disk>/queue/minimum_io_size
106Date: April 2009
107Contact: Martin K. Petersen <martin.petersen@oracle.com>
108Description:
Martin K. Petersen7e5f5fb2009-07-31 11:49:13 -0400109 Storage devices may report a granularity or preferred
110 minimum I/O size which is the smallest request the
111 device can perform without incurring a performance
112 penalty. For disk drives this is often the physical
113 block size. For RAID arrays it is often the stripe
114 chunk size. A properly aligned multiple of
115 minimum_io_size is the preferred request size for
116 workloads where a high number of I/O operations is
117 desired.
Martin K. Petersenc72758f2009-05-22 17:17:53 -0400118
119What: /sys/block/<disk>/queue/optimal_io_size
120Date: April 2009
121Contact: Martin K. Petersen <martin.petersen@oracle.com>
122Description:
123 Storage devices may report an optimal I/O size, which is
Martin K. Petersen7e5f5fb2009-07-31 11:49:13 -0400124 the device's preferred unit for sustained I/O. This is
125 rarely reported for disk drives. For RAID arrays it is
126 usually the stripe width or the internal track size. A
127 properly aligned multiple of optimal_io_size is the
128 preferred request size for workloads where sustained
129 throughput is desired. If no optimal I/O size is
130 reported this file contains 0.
Alan D. Brunelle488991e2010-01-29 09:04:08 +0100131
132What: /sys/block/<disk>/queue/nomerges
133Date: January 2010
134Contact:
135Description:
136 Standard I/O elevator operations include attempts to
137 merge contiguous I/Os. For known random I/O loads these
138 attempts will always fail and result in extra cycles
139 being spent in the kernel. This allows one to turn off
140 this behavior on one of two ways: When set to 1, complex
141 merge checks are disabled, but the simple one-shot merges
142 with the previous I/O request are enabled. When set to 2,
143 all merge tries are disabled. The default value is 0 -
144 which enables all types of merge tries.