1What:		/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:
7		 1 - reads completed successfully
8		 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.
29
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/device_is_integrity_capable
57Date:		July 2014
58Contact:	Martin K. Petersen <martin.petersen@oracle.com>
59Description:
60		Indicates whether a storage device is capable of storing
61		integrity metadata. Set if the device is T10 PI-capable.
62
63
64What:		/sys/block/<disk>/integrity/write_generate
65Date:		June 2008
66Contact:	Martin K. Petersen <martin.petersen@oracle.com>
67Description:
68		Indicates whether the block layer should automatically
69		generate checksums for write requests bound for
70		devices that support receiving integrity metadata.
71
72What:		/sys/block/<disk>/alignment_offset
73Date:		April 2009
74Contact:	Martin K. Petersen <martin.petersen@oracle.com>
75Description:
76		Storage devices may report a physical block size that is
77		bigger than the logical block size (for instance a drive
78		with 4KB physical sectors exposing 512-byte logical
79		blocks to the operating system).  This parameter
80		indicates how many bytes the beginning of the device is
81		offset from the disk's natural alignment.
82
83What:		/sys/block/<disk>/<partition>/alignment_offset
84Date:		April 2009
85Contact:	Martin K. Petersen <martin.petersen@oracle.com>
86Description:
87		Storage devices may report a physical block size that is
88		bigger than the logical block size (for instance a drive
89		with 4KB physical sectors exposing 512-byte logical
90		blocks to the operating system).  This parameter
91		indicates how many bytes the beginning of the partition
92		is offset from the disk's natural alignment.
93
94What:		/sys/block/<disk>/queue/logical_block_size
95Date:		May 2009
96Contact:	Martin K. Petersen <martin.petersen@oracle.com>
97Description:
98		This is the smallest unit the storage device can
99		address.  It is typically 512 bytes.
100
101What:		/sys/block/<disk>/queue/physical_block_size
102Date:		May 2009
103Contact:	Martin K. Petersen <martin.petersen@oracle.com>
104Description:
105		This is the smallest unit a physical storage device can
106		write atomically.  It is usually the same as the logical
107		block size but may be bigger.  One example is SATA
108		drives with 4KB sectors that expose a 512-byte logical
109		block size to the operating system.  For stacked block
110		devices the physical_block_size variable contains the
111		maximum physical_block_size of the component devices.
112
113What:		/sys/block/<disk>/queue/minimum_io_size
114Date:		April 2009
115Contact:	Martin K. Petersen <martin.petersen@oracle.com>
116Description:
117		Storage devices may report a granularity or preferred
118		minimum I/O size which is the smallest request the
119		device can perform without incurring a performance
120		penalty.  For disk drives this is often the physical
121		block size.  For RAID arrays it is often the stripe
122		chunk size.  A properly aligned multiple of
123		minimum_io_size is the preferred request size for
124		workloads where a high number of I/O operations is
125		desired.
126
127What:		/sys/block/<disk>/queue/optimal_io_size
128Date:		April 2009
129Contact:	Martin K. Petersen <martin.petersen@oracle.com>
130Description:
131		Storage devices may report an optimal I/O size, which is
132		the device's preferred unit for sustained I/O.  This is
133		rarely reported for disk drives.  For RAID arrays it is
134		usually the stripe width or the internal track size.  A
135		properly aligned multiple of optimal_io_size is the
136		preferred request size for workloads where sustained
137		throughput is desired.  If no optimal I/O size is
138		reported this file contains 0.
139
140What:		/sys/block/<disk>/queue/nomerges
141Date:		January 2010
142Contact:
143Description:
144		Standard I/O elevator operations include attempts to
145		merge contiguous I/Os. For known random I/O loads these
146		attempts will always fail and result in extra cycles
147		being spent in the kernel. This allows one to turn off
148		this behavior on one of two ways: When set to 1, complex
149		merge checks are disabled, but the simple one-shot merges
150		with the previous I/O request are enabled. When set to 2,
151		all merge tries are disabled. The default value is 0 -
152		which enables all types of merge tries.
153
154What:		/sys/block/<disk>/discard_alignment
155Date:		May 2011
156Contact:	Martin K. Petersen <martin.petersen@oracle.com>
157Description:
158		Devices that support discard functionality may
159		internally allocate space in units that are bigger than
160		the exported logical block size. The discard_alignment
161		parameter indicates how many bytes the beginning of the
162		device is offset from the internal allocation unit's
163		natural alignment.
164
165What:		/sys/block/<disk>/<partition>/discard_alignment
166Date:		May 2011
167Contact:	Martin K. Petersen <martin.petersen@oracle.com>
168Description:
169		Devices that support discard functionality may
170		internally allocate space in units that are bigger than
171		the exported logical block size. The discard_alignment
172		parameter indicates how many bytes the beginning of the
173		partition is offset from the internal allocation unit's
174		natural alignment.
175
176What:		/sys/block/<disk>/queue/discard_granularity
177Date:		May 2011
178Contact:	Martin K. Petersen <martin.petersen@oracle.com>
179Description:
180		Devices that support discard functionality may
181		internally allocate space using units that are bigger
182		than the logical block size. The discard_granularity
183		parameter indicates the size of the internal allocation
184		unit in bytes if reported by the device. Otherwise the
185		discard_granularity will be set to match the device's
186		physical block size. A discard_granularity of 0 means
187		that the device does not support discard functionality.
188
189What:		/sys/block/<disk>/queue/discard_max_bytes
190Date:		May 2011
191Contact:	Martin K. Petersen <martin.petersen@oracle.com>
192Description:
193		Devices that support discard functionality may have
194		internal limits on the number of bytes that can be
195		trimmed or unmapped in a single operation. Some storage
196		protocols also have inherent limits on the number of
197		blocks that can be described in a single command. The
198		discard_max_bytes parameter is set by the device driver
199		to the maximum number of bytes that can be discarded in
200		a single operation. Discard requests issued to the
201		device must not exceed this limit. A discard_max_bytes
202		value of 0 means that the device does not support
203		discard functionality.
204
205What:		/sys/block/<disk>/queue/discard_zeroes_data
206Date:		May 2011
207Contact:	Martin K. Petersen <martin.petersen@oracle.com>
208Description:
209		Devices that support discard functionality may return
210		stale or random data when a previously discarded block
211		is read back. This can cause problems if the filesystem
212		expects discarded blocks to be explicitly cleared. If a
213		device reports that it deterministically returns zeroes
214		when a discarded area is read the discard_zeroes_data
215		parameter will be set to one. Otherwise it will be 0 and
216		the result of reading a discarded area is undefined.
217
218What:		/sys/block/<disk>/queue/write_same_max_bytes
219Date:		January 2012
220Contact:	Martin K. Petersen <martin.petersen@oracle.com>
221Description:
222		Some devices support a write same operation in which a
223		single data block can be written to a range of several
224		contiguous blocks on storage. This can be used to wipe
225		areas on disk or to initialize drives in a RAID
226		configuration. write_same_max_bytes indicates how many
227		bytes can be written in a single write same command. If
228		write_same_max_bytes is 0, write same is not supported
229		by the device.
230
231