Linux Audio

Check our new training course

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