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