1What:		/sys/block/<disk>/alignment_offset
2Date:		April 2009
3Contact:	Martin K. Petersen <martin.petersen@oracle.com>
4Description:
5		Storage devices may report a physical block size that is
6		bigger than the logical block size (for instance a drive
7		with 4KB physical sectors exposing 512-byte logical
8		blocks to the operating system).  This parameter
9		indicates how many bytes the beginning of the device is
10		offset from the disk's natural alignment.
11
12
13What:		/sys/block/<disk>/discard_alignment
14Date:		May 2011
15Contact:	Martin K. Petersen <martin.petersen@oracle.com>
16Description:
17		Devices that support discard functionality may
18		internally allocate space in units that are bigger than
19		the exported logical block size. The discard_alignment
20		parameter indicates how many bytes the beginning of the
21		device is offset from the internal allocation unit's
22		natural alignment.
23
24
25What:		/sys/block/<disk>/diskseq
26Date:		February 2021
27Contact:	Matteo Croce <mcroce@microsoft.com>
28Description:
29		The /sys/block/<disk>/diskseq files reports the disk
30		sequence number, which is a monotonically increasing
31		number assigned to every drive.
32		Some devices, like the loop device, refresh such number
33		every time the backing file is changed.
34		The value type is 64 bit unsigned.
35
36
37What:		/sys/block/<disk>/inflight
38Date:		October 2009
39Contact:	Jens Axboe <axboe@kernel.dk>, Nikanth Karthikesan <knikanth@suse.de>
40Description:
41		Reports the number of I/O requests currently in progress
42		(pending / in flight) in a device driver. This can be less
43		than the number of requests queued in the block device queue.
44		The report contains 2 fields: one for read requests
45		and one for write requests.
46		The value type is unsigned int.
47		Cf. Documentation/block/stat.rst which contains a single value for
48		requests in flight.
49		This is related to /sys/block/<disk>/queue/nr_requests
50		and for SCSI device also its queue_depth.
51
52
53What:		/sys/block/<disk>/integrity/device_is_integrity_capable
54Date:		July 2014
55Contact:	Martin K. Petersen <martin.petersen@oracle.com>
56Description:
57		Indicates whether a storage device is capable of storing
58		integrity metadata. Set if the device is T10 PI-capable.
59
60
61What:		/sys/block/<disk>/integrity/format
62Date:		June 2008
63Contact:	Martin K. Petersen <martin.petersen@oracle.com>
64Description:
65		Metadata format for integrity capable block device.
66		E.g. T10-DIF-TYPE1-CRC.
67
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
77
78What:		/sys/block/<disk>/integrity/read_verify
79Date:		June 2008
80Contact:	Martin K. Petersen <martin.petersen@oracle.com>
81Description:
82		Indicates whether the block layer should verify the
83		integrity of read requests serviced by devices that
84		support sending integrity metadata.
85
86
87What:		/sys/block/<disk>/integrity/tag_size
88Date:		June 2008
89Contact:	Martin K. Petersen <martin.petersen@oracle.com>
90Description:
91		Number of bytes of integrity tag space available per
92		512 bytes of data.
93
94
95What:		/sys/block/<disk>/integrity/write_generate
96Date:		June 2008
97Contact:	Martin K. Petersen <martin.petersen@oracle.com>
98Description:
99		Indicates whether the block layer should automatically
100		generate checksums for write requests bound for
101		devices that support receiving integrity metadata.
102
103
104What:		/sys/block/<disk>/partscan
105Date:		May 2024
106Contact:	Christoph Hellwig <hch@lst.de>
107Description:
108		The /sys/block/<disk>/partscan files reports if partition
109		scanning is enabled for the disk.  It returns "1" if partition
110		scanning is enabled, or "0" if not.  The value type is a 32-bit
111		unsigned integer, but only "0" and "1" are valid values.
112
113
114What:		/sys/block/<disk>/<partition>/alignment_offset
115Date:		April 2009
116Contact:	Martin K. Petersen <martin.petersen@oracle.com>
117Description:
118		Storage devices may report a physical block size that is
119		bigger than the logical block size (for instance a drive
120		with 4KB physical sectors exposing 512-byte logical
121		blocks to the operating system).  This parameter
122		indicates how many bytes the beginning of the partition
123		is offset from the disk's natural alignment.
124
125
126What:		/sys/block/<disk>/<partition>/discard_alignment
127Date:		May 2011
128Contact:	Martin K. Petersen <martin.petersen@oracle.com>
129Description:
130		Devices that support discard functionality may
131		internally allocate space in units that are bigger than
132		the exported logical block size. The discard_alignment
133		parameter indicates how many bytes the beginning of the
134		partition is offset from the internal allocation unit's
135		natural alignment.
136
137
138What:		/sys/block/<disk>/<partition>/stat
139Date:		February 2008
140Contact:	Jerome Marchand <jmarchan@redhat.com>
141Description:
142		The /sys/block/<disk>/<partition>/stat files display the
143		I/O statistics of partition <partition>. The format is the
144		same as the format of /sys/block/<disk>/stat.
145
146
147What:		/sys/block/<disk>/queue/add_random
148Date:		June 2010
149Contact:	linux-block@vger.kernel.org
150Description:
151		[RW] This file allows to turn off the disk entropy contribution.
152		Default value of this file is '1'(on).
153
154
155What:		/sys/block/<disk>/queue/chunk_sectors
156Date:		September 2016
157Contact:	Hannes Reinecke <hare@suse.com>
158Description:
159		[RO] chunk_sectors has different meaning depending on the type
160		of the disk. For a RAID device (dm-raid), chunk_sectors
161		indicates the size in 512B sectors of the RAID volume stripe
162		segment. For a zoned block device, either host-aware or
163		host-managed, chunk_sectors indicates the size in 512B sectors
164		of the zones of the device, with the eventual exception of the
165		last zone of the device which may be smaller.
166
167
168What:		/sys/block/<disk>/queue/crypto/
169Date:		February 2022
170Contact:	linux-block@vger.kernel.org
171Description:
172		The presence of this subdirectory of /sys/block/<disk>/queue/
173		indicates that the device supports inline encryption.  This
174		subdirectory contains files which describe the inline encryption
175		capabilities of the device.  For more information about inline
176		encryption, refer to Documentation/block/inline-encryption.rst.
177
178
179What:		/sys/block/<disk>/queue/crypto/max_dun_bits
180Date:		February 2022
181Contact:	linux-block@vger.kernel.org
182Description:
183		[RO] This file shows the maximum length, in bits, of data unit
184		numbers accepted by the device in inline encryption requests.
185
186
187What:		/sys/block/<disk>/queue/crypto/modes/<mode>
188Date:		February 2022
189Contact:	linux-block@vger.kernel.org
190Description:
191		[RO] For each crypto mode (i.e., encryption/decryption
192		algorithm) the device supports with inline encryption, a file
193		will exist at this location.  It will contain a hexadecimal
194		number that is a bitmask of the supported data unit sizes, in
195		bytes, for that crypto mode.
196
197		Currently, the crypto modes that may be supported are:
198
199		   * AES-256-XTS
200		   * AES-128-CBC-ESSIV
201		   * Adiantum
202
203		For example, if a device supports AES-256-XTS inline encryption
204		with data unit sizes of 512 and 4096 bytes, the file
205		/sys/block/<disk>/queue/crypto/modes/AES-256-XTS will exist and
206		will contain "0x1200".
207
208
209What:		/sys/block/<disk>/queue/crypto/num_keyslots
210Date:		February 2022
211Contact:	linux-block@vger.kernel.org
212Description:
213		[RO] This file shows the number of keyslots the device has for
214		use with inline encryption.
215
216
217What:		/sys/block/<disk>/queue/dax
218Date:		June 2016
219Contact:	linux-block@vger.kernel.org
220Description:
221		[RO] This file indicates whether the device supports Direct
222		Access (DAX), used by CPU-addressable storage to bypass the
223		pagecache.  It shows '1' if true, '0' if not.
224
225
226What:		/sys/block/<disk>/queue/discard_granularity
227Date:		May 2011
228Contact:	Martin K. Petersen <martin.petersen@oracle.com>
229Description:
230		[RO] Devices that support discard functionality may internally
231		allocate space using units that are bigger than the logical
232		block size. The discard_granularity parameter indicates the size
233		of the internal allocation unit in bytes if reported by the
234		device. Otherwise the discard_granularity will be set to match
235		the device's physical block size. A discard_granularity of 0
236		means that the device does not support discard functionality.
237
238
239What:		/sys/block/<disk>/queue/discard_max_bytes
240Date:		May 2011
241Contact:	Martin K. Petersen <martin.petersen@oracle.com>
242Description:
243		[RW] While discard_max_hw_bytes is the hardware limit for the
244		device, this setting is the software limit. Some devices exhibit
245		large latencies when large discards are issued, setting this
246		value lower will make Linux issue smaller discards and
247		potentially help reduce latencies induced by large discard
248		operations.
249
250
251What:		/sys/block/<disk>/queue/discard_max_hw_bytes
252Date:		July 2015
253Contact:	linux-block@vger.kernel.org
254Description:
255		[RO] Devices that support discard functionality may have
256		internal limits on the number of bytes that can be trimmed or
257		unmapped in a single operation.  The `discard_max_hw_bytes`
258		parameter is set by the device driver to the maximum number of
259		bytes that can be discarded in a single operation.  Discard
260		requests issued to the device must not exceed this limit.  A
261		`discard_max_hw_bytes` value of 0 means that the device does not
262		support discard functionality.
263
264
265What:		/sys/block/<disk>/queue/discard_zeroes_data
266Date:		May 2011
267Contact:	Martin K. Petersen <martin.petersen@oracle.com>
268Description:
269		[RO] Will always return 0.  Don't rely on any specific behavior
270		for discards, and don't read this file.
271
272
273What:		/sys/block/<disk>/queue/dma_alignment
274Date:		May 2022
275Contact:	linux-block@vger.kernel.org
276Description:
277		Reports the alignment that user space addresses must have to be
278		used for raw block device access with O_DIRECT and other driver
279		specific passthrough mechanisms.
280
281
282What:		/sys/block/<disk>/queue/fua
283Date:		May 2018
284Contact:	linux-block@vger.kernel.org
285Description:
286		[RO] Whether or not the block driver supports the FUA flag for
287		write requests.  FUA stands for Force Unit Access. If the FUA
288		flag is set that means that write requests must bypass the
289		volatile cache of the storage device.
290
291
292What:		/sys/block/<disk>/queue/hw_sector_size
293Date:		January 2008
294Contact:	linux-block@vger.kernel.org
295Description:
296		[RO] This is the hardware sector size of the device, in bytes.
297
298
299What:		/sys/block/<disk>/queue/independent_access_ranges/
300Date:		October 2021
301Contact:	linux-block@vger.kernel.org
302Description:
303		[RO] The presence of this sub-directory of the
304		/sys/block/xxx/queue/ directory indicates that the device is
305		capable of executing requests targeting different sector ranges
306		in parallel. For instance, single LUN multi-actuator hard-disks
307		will have an independent_access_ranges directory if the device
308		correctly advertises the sector ranges of its actuators.
309
310		The independent_access_ranges directory contains one directory
311		per access range, with each range described using the sector
312		(RO) attribute file to indicate the first sector of the range
313		and the nr_sectors (RO) attribute file to indicate the total
314		number of sectors in the range starting from the first sector of
315		the range.  For example, a dual-actuator hard-disk will have the
316		following independent_access_ranges entries.::
317
318			$ tree /sys/block/<disk>/queue/independent_access_ranges/
319			/sys/block/<disk>/queue/independent_access_ranges/
320			|-- 0
321			|   |-- nr_sectors
322			|   `-- sector
323			`-- 1
324			    |-- nr_sectors
325			    `-- sector
326
327		The sector and nr_sectors attributes use 512B sector unit,
328		regardless of the actual block size of the device. Independent
329		access ranges do not overlap and include all sectors within the
330		device capacity. The access ranges are numbered in increasing
331		order of the range start sector, that is, the sector attribute
332		of range 0 always has the value 0.
333
334
335What:		/sys/block/<disk>/queue/io_poll
336Date:		November 2015
337Contact:	linux-block@vger.kernel.org
338Description:
339		[RW] When read, this file shows whether polling is enabled (1)
340		or disabled (0).  Writing '0' to this file will disable polling
341		for this device.  Writing any non-zero value will enable this
342		feature.
343
344
345What:		/sys/block/<disk>/queue/io_poll_delay
346Date:		November 2016
347Contact:	linux-block@vger.kernel.org
348Description:
349		[RW] This was used to control what kind of polling will be
350		performed.  It is now fixed to -1, which is classic polling.
351		In this mode, the CPU will repeatedly ask for completions
352		without giving up any time.
353		<deprecated>
354
355
356What:		/sys/block/<disk>/queue/io_timeout
357Date:		November 2018
358Contact:	Weiping Zhang <zhangweiping@didiglobal.com>
359Description:
360		[RW] io_timeout is the request timeout in milliseconds. If a
361		request does not complete in this time then the block driver
362		timeout handler is invoked. That timeout handler can decide to
363		retry the request, to fail it or to start a device recovery
364		strategy.
365
366
367What:		/sys/block/<disk>/queue/iostats
368Date:		January 2009
369Contact:	linux-block@vger.kernel.org
370Description:
371		[RW] This file is used to control (on/off) the iostats
372		accounting of the disk.
373
374
375What:		/sys/block/<disk>/queue/logical_block_size
376Date:		May 2009
377Contact:	Martin K. Petersen <martin.petersen@oracle.com>
378Description:
379		[RO] This is the smallest unit the storage device can address.
380		It is typically 512 bytes.
381
382
383What:		/sys/block/<disk>/queue/max_active_zones
384Date:		July 2020
385Contact:	Niklas Cassel <niklas.cassel@wdc.com>
386Description:
387		[RO] For zoned block devices (zoned attribute indicating
388		"host-managed" or "host-aware"), the sum of zones belonging to
389		any of the zone states: EXPLICIT OPEN, IMPLICIT OPEN or CLOSED,
390		is limited by this value. If this value is 0, there is no limit.
391
392		If the host attempts to exceed this limit, the driver should
393		report this error with BLK_STS_ZONE_ACTIVE_RESOURCE, which user
394		space may see as the EOVERFLOW errno.
395
396
397What:		/sys/block/<disk>/queue/max_discard_segments
398Date:		February 2017
399Contact:	linux-block@vger.kernel.org
400Description:
401		[RO] The maximum number of DMA scatter/gather entries in a
402		discard request.
403
404
405What:		/sys/block/<disk>/queue/max_hw_sectors_kb
406Date:		September 2004
407Contact:	linux-block@vger.kernel.org
408Description:
409		[RO] This is the maximum number of kilobytes supported in a
410		single data transfer.
411
412
413What:		/sys/block/<disk>/queue/max_integrity_segments
414Date:		September 2010
415Contact:	linux-block@vger.kernel.org
416Description:
417		[RO] Maximum number of elements in a DMA scatter/gather list
418		with integrity data that will be submitted by the block layer
419		core to the associated block driver.
420
421
422What:		/sys/block/<disk>/queue/max_open_zones
423Date:		July 2020
424Contact:	Niklas Cassel <niklas.cassel@wdc.com>
425Description:
426		[RO] For zoned block devices (zoned attribute indicating
427		"host-managed" or "host-aware"), the sum of zones belonging to
428		any of the zone states: EXPLICIT OPEN or IMPLICIT OPEN, is
429		limited by this value. If this value is 0, there is no limit.
430
431
432What:		/sys/block/<disk>/queue/max_sectors_kb
433Date:		September 2004
434Contact:	linux-block@vger.kernel.org
435Description:
436		[RW] This is the maximum number of kilobytes that the block
437		layer will allow for a filesystem request. Must be smaller than
438		or equal to the maximum size allowed by the hardware. Write 0
439		to use default kernel settings.
440
441
442What:		/sys/block/<disk>/queue/max_segment_size
443Date:		March 2010
444Contact:	linux-block@vger.kernel.org
445Description:
446		[RO] Maximum size in bytes of a single element in a DMA
447		scatter/gather list.
448
449
450What:		/sys/block/<disk>/queue/max_segments
451Date:		March 2010
452Contact:	linux-block@vger.kernel.org
453Description:
454		[RO] Maximum number of elements in a DMA scatter/gather list
455		that is submitted to the associated block driver.
456
457
458What:		/sys/block/<disk>/queue/minimum_io_size
459Date:		April 2009
460Contact:	Martin K. Petersen <martin.petersen@oracle.com>
461Description:
462		[RO] Storage devices may report a granularity or preferred
463		minimum I/O size which is the smallest request the device can
464		perform without incurring a performance penalty.  For disk
465		drives this is often the physical block size.  For RAID arrays
466		it is often the stripe chunk size.  A properly aligned multiple
467		of minimum_io_size is the preferred request size for workloads
468		where a high number of I/O operations is desired.
469
470
471What:		/sys/block/<disk>/queue/nomerges
472Date:		January 2010
473Contact:	linux-block@vger.kernel.org
474Description:
475		[RW] Standard I/O elevator operations include attempts to merge
476		contiguous I/Os. For known random I/O loads these attempts will
477		always fail and result in extra cycles being spent in the
478		kernel. This allows one to turn off this behavior on one of two
479		ways: When set to 1, complex merge checks are disabled, but the
480		simple one-shot merges with the previous I/O request are
481		enabled. When set to 2, all merge tries are disabled. The
482		default value is 0 - which enables all types of merge tries.
483
484
485What:		/sys/block/<disk>/queue/nr_requests
486Date:		July 2003
487Contact:	linux-block@vger.kernel.org
488Description:
489		[RW] This controls how many requests may be allocated in the
490		block layer for read or write requests. Note that the total
491		allocated number may be twice this amount, since it applies only
492		to reads or writes (not the accumulated sum).
493
494		To avoid priority inversion through request starvation, a
495		request queue maintains a separate request pool per each cgroup
496		when CONFIG_BLK_CGROUP is enabled, and this parameter applies to
497		each such per-block-cgroup request pool.  IOW, if there are N
498		block cgroups, each request queue may have up to N request
499		pools, each independently regulated by nr_requests.
500
501
502What:		/sys/block/<disk>/queue/nr_zones
503Date:		November 2018
504Contact:	Damien Le Moal <damien.lemoal@wdc.com>
505Description:
506		[RO] nr_zones indicates the total number of zones of a zoned
507		block device ("host-aware" or "host-managed" zone model). For
508		regular block devices, the value is always 0.
509
510
511What:		/sys/block/<disk>/queue/optimal_io_size
512Date:		April 2009
513Contact:	Martin K. Petersen <martin.petersen@oracle.com>
514Description:
515		[RO] Storage devices may report an optimal I/O size, which is
516		the device's preferred unit for sustained I/O.  This is rarely
517		reported for disk drives.  For RAID arrays it is usually the
518		stripe width or the internal track size.  A properly aligned
519		multiple of optimal_io_size is the preferred request size for
520		workloads where sustained throughput is desired.  If no optimal
521		I/O size is reported this file contains 0.
522
523
524What:		/sys/block/<disk>/queue/physical_block_size
525Date:		May 2009
526Contact:	Martin K. Petersen <martin.petersen@oracle.com>
527Description:
528		[RO] This is the smallest unit a physical storage device can
529		write atomically.  It is usually the same as the logical block
530		size but may be bigger.  One example is SATA drives with 4KB
531		sectors that expose a 512-byte logical block size to the
532		operating system.  For stacked block devices the
533		physical_block_size variable contains the maximum
534		physical_block_size of the component devices.
535
536
537What:		/sys/block/<disk>/queue/read_ahead_kb
538Date:		May 2004
539Contact:	linux-block@vger.kernel.org
540Description:
541		[RW] Maximum number of kilobytes to read-ahead for filesystems
542		on this block device.
543
544
545What:		/sys/block/<disk>/queue/rotational
546Date:		January 2009
547Contact:	linux-block@vger.kernel.org
548Description:
549		[RW] This file is used to stat if the device is of rotational
550		type or non-rotational type.
551
552
553What:		/sys/block/<disk>/queue/rq_affinity
554Date:		September 2008
555Contact:	linux-block@vger.kernel.org
556Description:
557		[RW] If this option is '1', the block layer will migrate request
558		completions to the cpu "group" that originally submitted the
559		request. For some workloads this provides a significant
560		reduction in CPU cycles due to caching effects.
561
562		For storage configurations that need to maximize distribution of
563		completion processing setting this option to '2' forces the
564		completion to run on the requesting cpu (bypassing the "group"
565		aggregation logic).
566
567
568What:		/sys/block/<disk>/queue/scheduler
569Date:		October 2004
570Contact:	linux-block@vger.kernel.org
571Description:
572		[RW] When read, this file will display the current and available
573		IO schedulers for this block device. The currently active IO
574		scheduler will be enclosed in [] brackets. Writing an IO
575		scheduler name to this file will switch control of this block
576		device to that new IO scheduler. Note that writing an IO
577		scheduler name to this file will attempt to load that IO
578		scheduler module, if it isn't already present in the system.
579
580
581What:		/sys/block/<disk>/queue/stable_writes
582Date:		September 2020
583Contact:	linux-block@vger.kernel.org
584Description:
585		[RW] This file will contain '1' if memory must not be modified
586		while it is being used in a write request to this device.  When
587		this is the case and the kernel is performing writeback of a
588		page, the kernel will wait for writeback to complete before
589		allowing the page to be modified again, rather than allowing
590		immediate modification as is normally the case.  This
591		restriction arises when the device accesses the memory multiple
592		times where the same data must be seen every time -- for
593		example, once to calculate a checksum and once to actually write
594		the data.  If no such restriction exists, this file will contain
595		'0'.  This file is writable for testing purposes.
596
597
598What:		/sys/block/<disk>/queue/throttle_sample_time
599Date:		March 2017
600Contact:	linux-block@vger.kernel.org
601Description:
602		[RW] This is the time window that blk-throttle samples data, in
603		millisecond.  blk-throttle makes decision based on the
604		samplings. Lower time means cgroups have more smooth throughput,
605		but higher CPU overhead. This exists only when
606		CONFIG_BLK_DEV_THROTTLING_LOW is enabled.
607
608
609What:		/sys/block/<disk>/queue/virt_boundary_mask
610Date:		April 2021
611Contact:	linux-block@vger.kernel.org
612Description:
613		[RO] This file shows the I/O segment memory alignment mask for
614		the block device.  I/O requests to this device will be split
615		between segments wherever either the memory address of the end
616		of the previous segment or the memory address of the beginning
617		of the current segment is not aligned to virt_boundary_mask + 1
618		bytes.
619
620
621What:		/sys/block/<disk>/queue/wbt_lat_usec
622Date:		November 2016
623Contact:	linux-block@vger.kernel.org
624Description:
625		[RW] If the device is registered for writeback throttling, then
626		this file shows the target minimum read latency. If this latency
627		is exceeded in a given window of time (see wb_window_usec), then
628		the writeback throttling will start scaling back writes. Writing
629		a value of '0' to this file disables the feature. Writing a
630		value of '-1' to this file resets the value to the default
631		setting.
632
633
634What:		/sys/block/<disk>/queue/write_cache
635Date:		April 2016
636Contact:	linux-block@vger.kernel.org
637Description:
638		[RW] When read, this file will display whether the device has
639		write back caching enabled or not. It will return "write back"
640		for the former case, and "write through" for the latter. Writing
641		to this file can change the kernels view of the device, but it
642		doesn't alter the device state. This means that it might not be
643		safe to toggle the setting from "write back" to "write through",
644		since that will also eliminate cache flushes issued by the
645		kernel.
646
647
648What:		/sys/block/<disk>/queue/write_same_max_bytes
649Date:		January 2012
650Contact:	Martin K. Petersen <martin.petersen@oracle.com>
651Description:
652		[RO] Some devices support a write same operation in which a
653		single data block can be written to a range of several
654		contiguous blocks on storage. This can be used to wipe areas on
655		disk or to initialize drives in a RAID configuration.
656		write_same_max_bytes indicates how many bytes can be written in
657		a single write same command. If write_same_max_bytes is 0, write
658		same is not supported by the device.
659
660
661What:		/sys/block/<disk>/queue/write_zeroes_max_bytes
662Date:		November 2016
663Contact:	Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
664Description:
665		[RO] Devices that support write zeroes operation in which a
666		single request can be issued to zero out the range of contiguous
667		blocks on storage without having any payload in the request.
668		This can be used to optimize writing zeroes to the devices.
669		write_zeroes_max_bytes indicates how many bytes can be written
670		in a single write zeroes command. If write_zeroes_max_bytes is
671		0, write zeroes is not supported by the device.
672
673
674What:		/sys/block/<disk>/queue/zone_append_max_bytes
675Date:		May 2020
676Contact:	linux-block@vger.kernel.org
677Description:
678		[RO] This is the maximum number of bytes that can be written to
679		a sequential zone of a zoned block device using a zone append
680		write operation (REQ_OP_ZONE_APPEND). This value is always 0 for
681		regular block devices.
682
683
684What:		/sys/block/<disk>/queue/zone_write_granularity
685Date:		January 2021
686Contact:	linux-block@vger.kernel.org
687Description:
688		[RO] This indicates the alignment constraint, in bytes, for
689		write operations in sequential zones of zoned block devices
690		(devices with a zoned attributed that reports "host-managed" or
691		"host-aware"). This value is always 0 for regular block devices.
692
693
694What:		/sys/block/<disk>/queue/zoned
695Date:		September 2016
696Contact:	Damien Le Moal <damien.lemoal@wdc.com>
697Description:
698		[RO] zoned indicates if the device is a zoned block device and
699		the zone model of the device if it is indeed zoned.  The
700		possible values indicated by zoned are "none" for regular block
701		devices and "host-aware" or "host-managed" for zoned block
702		devices. The characteristics of host-aware and host-managed
703		zoned block devices are described in the ZBC (Zoned Block
704		Commands) and ZAC (Zoned Device ATA Command Set) standards.
705		These standards also define the "drive-managed" zone model.
706		However, since drive-managed zoned block devices do not support
707		zone commands, they will be treated as regular block devices and
708		zoned will report "none".
709
710
711What:		/sys/block/<disk>/hidden
712Date:		March 2023
713Contact:	linux-block@vger.kernel.org
714Description:
715		[RO] the block device is hidden. it doesn’t produce events, and
716		can’t be opened from userspace or using blkdev_get*.
717		Used for the underlying components of multipath devices.
718
719
720What:		/sys/block/<disk>/stat
721Date:		February 2008
722Contact:	Jerome Marchand <jmarchan@redhat.com>
723Description:
724		The /sys/block/<disk>/stat files displays the I/O
725		statistics of disk <disk>. They contain 11 fields:
726
727		==  ==============================================
728		 1  reads completed successfully
729		 2  reads merged
730		 3  sectors read
731		 4  time spent reading (ms)
732		 5  writes completed
733		 6  writes merged
734		 7  sectors written
735		 8  time spent writing (ms)
736		 9  I/Os currently in progress
737		10  time spent doing I/Os (ms)
738		11  weighted time spent doing I/Os (ms)
739		12  discards completed
740		13  discards merged
741		14  sectors discarded
742		15  time spent discarding (ms)
743		16  flush requests completed
744		17  time spent flushing (ms)
745		==  ==============================================
746
747		For more details refer Documentation/admin-guide/iostats.rst
748