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
8		==  ==============================================
9		 1  reads completed successfully
10		 2  reads merged
11		 3  sectors read
12		 4  time spent reading (ms)
13		 5  writes completed
14		 6  writes merged
15		 7  sectors written
16		 8  time spent writing (ms)
17		 9  I/Os currently in progress
18		10  time spent doing I/Os (ms)
19		11  weighted time spent doing I/Os (ms)
20		12  discards completed
21		13  discards merged
22		14  sectors discarded
23		15  time spent discarding (ms)
24		16  flush requests completed
25		17  time spent flushing (ms)
26		==  ==============================================
27
28		For more details refer Documentation/admin-guide/iostats.rst
29
30
31What:		/sys/block/<disk>/inflight
32Date:		October 2009
33Contact:	Jens Axboe <axboe@kernel.dk>, Nikanth Karthikesan <knikanth@suse.de>
34Description:
35		Reports the number of I/O requests currently in progress
36		(pending / in flight) in a device driver. This can be less
37		than the number of requests queued in the block device queue.
38		The report contains 2 fields: one for read requests
39		and one for write requests.
40		The value type is unsigned int.
41		Cf. Documentation/block/stat.rst which contains a single value for
42		requests in flight.
43		This is related to nr_requests in Documentation/block/queue-sysfs.rst
44		and for SCSI device also its queue_depth.
45
46
47What:		/sys/block/<disk>/diskseq
48Date:		February 2021
49Contact:	Matteo Croce <mcroce@microsoft.com>
50Description:
51		The /sys/block/<disk>/diskseq files reports the disk
52		sequence number, which is a monotonically increasing
53		number assigned to every drive.
54		Some devices, like the loop device, refresh such number
55		every time the backing file is changed.
56		The value type is 64 bit unsigned.
57
58
59What:		/sys/block/<disk>/<part>/stat
60Date:		February 2008
61Contact:	Jerome Marchand <jmarchan@redhat.com>
62Description:
63		The /sys/block/<disk>/<part>/stat files display the
64		I/O statistics of partition <part>. The format is the
65		same as the above-written /sys/block/<disk>/stat
66		format.
67
68
69What:		/sys/block/<disk>/integrity/format
70Date:		June 2008
71Contact:	Martin K. Petersen <martin.petersen@oracle.com>
72Description:
73		Metadata format for integrity capable block device.
74		E.g. T10-DIF-TYPE1-CRC.
75
76
77What:		/sys/block/<disk>/integrity/read_verify
78Date:		June 2008
79Contact:	Martin K. Petersen <martin.petersen@oracle.com>
80Description:
81		Indicates whether the block layer should verify the
82		integrity of read requests serviced by devices that
83		support sending integrity metadata.
84
85
86What:		/sys/block/<disk>/integrity/tag_size
87Date:		June 2008
88Contact:	Martin K. Petersen <martin.petersen@oracle.com>
89Description:
90		Number of bytes of integrity tag space available per
91		512 bytes of data.
92
93
94What:		/sys/block/<disk>/integrity/device_is_integrity_capable
95Date:		July 2014
96Contact:	Martin K. Petersen <martin.petersen@oracle.com>
97Description:
98		Indicates whether a storage device is capable of storing
99		integrity metadata. Set if the device is T10 PI-capable.
100
101What:		/sys/block/<disk>/integrity/protection_interval_bytes
102Date:		July 2015
103Contact:	Martin K. Petersen <martin.petersen@oracle.com>
104Description:
105		Describes the number of data bytes which are protected
106		by one integrity tuple. Typically the device's logical
107		block size.
108
109What:		/sys/block/<disk>/integrity/write_generate
110Date:		June 2008
111Contact:	Martin K. Petersen <martin.petersen@oracle.com>
112Description:
113		Indicates whether the block layer should automatically
114		generate checksums for write requests bound for
115		devices that support receiving integrity metadata.
116
117What:		/sys/block/<disk>/alignment_offset
118Date:		April 2009
119Contact:	Martin K. Petersen <martin.petersen@oracle.com>
120Description:
121		Storage devices may report a physical block size that is
122		bigger than the logical block size (for instance a drive
123		with 4KB physical sectors exposing 512-byte logical
124		blocks to the operating system).  This parameter
125		indicates how many bytes the beginning of the device is
126		offset from the disk's natural alignment.
127
128What:		/sys/block/<disk>/<partition>/alignment_offset
129Date:		April 2009
130Contact:	Martin K. Petersen <martin.petersen@oracle.com>
131Description:
132		Storage devices may report a physical block size that is
133		bigger than the logical block size (for instance a drive
134		with 4KB physical sectors exposing 512-byte logical
135		blocks to the operating system).  This parameter
136		indicates how many bytes the beginning of the partition
137		is offset from the disk's natural alignment.
138
139What:		/sys/block/<disk>/queue/logical_block_size
140Date:		May 2009
141Contact:	Martin K. Petersen <martin.petersen@oracle.com>
142Description:
143		This is the smallest unit the storage device can
144		address.  It is typically 512 bytes.
145
146What:		/sys/block/<disk>/queue/physical_block_size
147Date:		May 2009
148Contact:	Martin K. Petersen <martin.petersen@oracle.com>
149Description:
150		This is the smallest unit a physical storage device can
151		write atomically.  It is usually the same as the logical
152		block size but may be bigger.  One example is SATA
153		drives with 4KB sectors that expose a 512-byte logical
154		block size to the operating system.  For stacked block
155		devices the physical_block_size variable contains the
156		maximum physical_block_size of the component devices.
157
158What:		/sys/block/<disk>/queue/minimum_io_size
159Date:		April 2009
160Contact:	Martin K. Petersen <martin.petersen@oracle.com>
161Description:
162		Storage devices may report a granularity or preferred
163		minimum I/O size which is the smallest request the
164		device can perform without incurring a performance
165		penalty.  For disk drives this is often the physical
166		block size.  For RAID arrays it is often the stripe
167		chunk size.  A properly aligned multiple of
168		minimum_io_size is the preferred request size for
169		workloads where a high number of I/O operations is
170		desired.
171
172What:		/sys/block/<disk>/queue/optimal_io_size
173Date:		April 2009
174Contact:	Martin K. Petersen <martin.petersen@oracle.com>
175Description:
176		Storage devices may report an optimal I/O size, which is
177		the device's preferred unit for sustained I/O.  This is
178		rarely reported for disk drives.  For RAID arrays it is
179		usually the stripe width or the internal track size.  A
180		properly aligned multiple of optimal_io_size is the
181		preferred request size for workloads where sustained
182		throughput is desired.  If no optimal I/O size is
183		reported this file contains 0.
184
185What:		/sys/block/<disk>/queue/nomerges
186Date:		January 2010
187Contact:
188Description:
189		Standard I/O elevator operations include attempts to
190		merge contiguous I/Os. For known random I/O loads these
191		attempts will always fail and result in extra cycles
192		being spent in the kernel. This allows one to turn off
193		this behavior on one of two ways: When set to 1, complex
194		merge checks are disabled, but the simple one-shot merges
195		with the previous I/O request are enabled. When set to 2,
196		all merge tries are disabled. The default value is 0 -
197		which enables all types of merge tries.
198
199What:		/sys/block/<disk>/discard_alignment
200Date:		May 2011
201Contact:	Martin K. Petersen <martin.petersen@oracle.com>
202Description:
203		Devices that support discard functionality may
204		internally allocate space in units that are bigger than
205		the exported logical block size. The discard_alignment
206		parameter indicates how many bytes the beginning of the
207		device is offset from the internal allocation unit's
208		natural alignment.
209
210What:		/sys/block/<disk>/<partition>/discard_alignment
211Date:		May 2011
212Contact:	Martin K. Petersen <martin.petersen@oracle.com>
213Description:
214		Devices that support discard functionality may
215		internally allocate space in units that are bigger than
216		the exported logical block size. The discard_alignment
217		parameter indicates how many bytes the beginning of the
218		partition is offset from the internal allocation unit's
219		natural alignment.
220
221What:		/sys/block/<disk>/queue/discard_granularity
222Date:		May 2011
223Contact:	Martin K. Petersen <martin.petersen@oracle.com>
224Description:
225		Devices that support discard functionality may
226		internally allocate space using units that are bigger
227		than the logical block size. The discard_granularity
228		parameter indicates the size of the internal allocation
229		unit in bytes if reported by the device. Otherwise the
230		discard_granularity will be set to match the device's
231		physical block size. A discard_granularity of 0 means
232		that the device does not support discard functionality.
233
234What:		/sys/block/<disk>/queue/discard_max_bytes
235Date:		May 2011
236Contact:	Martin K. Petersen <martin.petersen@oracle.com>
237Description:
238		Devices that support discard functionality may have
239		internal limits on the number of bytes that can be
240		trimmed or unmapped in a single operation. Some storage
241		protocols also have inherent limits on the number of
242		blocks that can be described in a single command. The
243		discard_max_bytes parameter is set by the device driver
244		to the maximum number of bytes that can be discarded in
245		a single operation. Discard requests issued to the
246		device must not exceed this limit. A discard_max_bytes
247		value of 0 means that the device does not support
248		discard functionality.
249
250What:		/sys/block/<disk>/queue/discard_zeroes_data
251Date:		May 2011
252Contact:	Martin K. Petersen <martin.petersen@oracle.com>
253Description:
254		Will always return 0.  Don't rely on any specific behavior
255		for discards, and don't read this file.
256
257What:		/sys/block/<disk>/queue/write_same_max_bytes
258Date:		January 2012
259Contact:	Martin K. Petersen <martin.petersen@oracle.com>
260Description:
261		Some devices support a write same operation in which a
262		single data block can be written to a range of several
263		contiguous blocks on storage. This can be used to wipe
264		areas on disk or to initialize drives in a RAID
265		configuration. write_same_max_bytes indicates how many
266		bytes can be written in a single write same command. If
267		write_same_max_bytes is 0, write same is not supported
268		by the device.
269
270What:		/sys/block/<disk>/queue/write_zeroes_max_bytes
271Date:		November 2016
272Contact:	Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
273Description:
274		Devices that support write zeroes operation in which a
275		single request can be issued to zero out the range of
276		contiguous blocks on storage without having any payload
277		in the request. This can be used to optimize writing zeroes
278		to the devices. write_zeroes_max_bytes indicates how many
279		bytes can be written in a single write zeroes command. If
280		write_zeroes_max_bytes is 0, write zeroes is not supported
281		by the device.
282
283What:		/sys/block/<disk>/queue/zoned
284Date:		September 2016
285Contact:	Damien Le Moal <damien.lemoal@wdc.com>
286Description:
287		zoned indicates if the device is a zoned block device
288		and the zone model of the device if it is indeed zoned.
289		The possible values indicated by zoned are "none" for
290		regular block devices and "host-aware" or "host-managed"
291		for zoned block devices. The characteristics of
292		host-aware and host-managed zoned block devices are
293		described in the ZBC (Zoned Block Commands) and ZAC
294		(Zoned Device ATA Command Set) standards. These standards
295		also define the "drive-managed" zone model. However,
296		since drive-managed zoned block devices do not support
297		zone commands, they will be treated as regular block
298		devices and zoned will report "none".
299
300What:		/sys/block/<disk>/queue/nr_zones
301Date:		November 2018
302Contact:	Damien Le Moal <damien.lemoal@wdc.com>
303Description:
304		nr_zones indicates the total number of zones of a zoned block
305		device ("host-aware" or "host-managed" zone model). For regular
306		block devices, the value is always 0.
307
308What:		/sys/block/<disk>/queue/max_active_zones
309Date:		July 2020
310Contact:	Niklas Cassel <niklas.cassel@wdc.com>
311Description:
312		For zoned block devices (zoned attribute indicating
313		"host-managed" or "host-aware"), the sum of zones belonging to
314		any of the zone states: EXPLICIT OPEN, IMPLICIT OPEN or CLOSED,
315		is limited by this value. If this value is 0, there is no limit.
316
317What:		/sys/block/<disk>/queue/max_open_zones
318Date:		July 2020
319Contact:	Niklas Cassel <niklas.cassel@wdc.com>
320Description:
321		For zoned block devices (zoned attribute indicating
322		"host-managed" or "host-aware"), the sum of zones belonging to
323		any of the zone states: EXPLICIT OPEN or IMPLICIT OPEN,
324		is limited by this value. If this value is 0, there is no limit.
325
326What:		/sys/block/<disk>/queue/chunk_sectors
327Date:		September 2016
328Contact:	Hannes Reinecke <hare@suse.com>
329Description:
330		chunk_sectors has different meaning depending on the type
331		of the disk. For a RAID device (dm-raid), chunk_sectors
332		indicates the size in 512B sectors of the RAID volume
333		stripe segment. For a zoned block device, either
334		host-aware or host-managed, chunk_sectors indicates the
335		size in 512B sectors of the zones of the device, with
336		the eventual exception of the last zone of the device
337		which may be smaller.
338
339What:		/sys/block/<disk>/queue/io_timeout
340Date:		November 2018
341Contact:	Weiping Zhang <zhangweiping@didiglobal.com>
342Description:
343		io_timeout is the request timeout in milliseconds. If a request
344		does not complete in this time then the block driver timeout
345		handler is invoked. That timeout handler can decide to retry
346		the request, to fail it or to start a device recovery strategy.
347