792 lines · plain
1What: /sys/block/<disk>/alignment_offset2Date: April 20093Contact: Martin K. Petersen <martin.petersen@oracle.com>4Description:5 Storage devices may report a physical block size that is6 bigger than the logical block size (for instance a drive7 with 4KB physical sectors exposing 512-byte logical8 blocks to the operating system). This parameter9 indicates how many bytes the beginning of the device is10 offset from the disk's natural alignment.11 12 13What: /sys/block/<disk>/discard_alignment14Date: May 201115Contact: Martin K. Petersen <martin.petersen@oracle.com>16Description:17 Devices that support discard functionality may18 internally allocate space in units that are bigger than19 the exported logical block size. The discard_alignment20 parameter indicates how many bytes the beginning of the21 device is offset from the internal allocation unit's22 natural alignment.23 24What: /sys/block/<disk>/atomic_write_max_bytes25Date: February 202426Contact: Himanshu Madhani <himanshu.madhani@oracle.com>27Description:28 [RO] This parameter specifies the maximum atomic write29 size reported by the device. This parameter is relevant30 for merging of writes, where a merged atomic write31 operation must not exceed this number of bytes.32 This parameter may be greater than the value in33 atomic_write_unit_max_bytes as34 atomic_write_unit_max_bytes will be rounded down to a35 power-of-two and atomic_write_unit_max_bytes may also be36 limited by some other queue limits, such as max_segments.37 This parameter - along with atomic_write_unit_min_bytes38 and atomic_write_unit_max_bytes - will not be larger than39 max_hw_sectors_kb, but may be larger than max_sectors_kb.40 41 42What: /sys/block/<disk>/atomic_write_unit_min_bytes43Date: February 202444Contact: Himanshu Madhani <himanshu.madhani@oracle.com>45Description:46 [RO] This parameter specifies the smallest block which can47 be written atomically with an atomic write operation. All48 atomic write operations must begin at a49 atomic_write_unit_min boundary and must be multiples of50 atomic_write_unit_min. This value must be a power-of-two.51 52 53What: /sys/block/<disk>/atomic_write_unit_max_bytes54Date: February 202455Contact: Himanshu Madhani <himanshu.madhani@oracle.com>56Description:57 [RO] This parameter defines the largest block which can be58 written atomically with an atomic write operation. This59 value must be a multiple of atomic_write_unit_min and must60 be a power-of-two. This value will not be larger than61 atomic_write_max_bytes.62 63 64What: /sys/block/<disk>/atomic_write_boundary_bytes65Date: February 202466Contact: Himanshu Madhani <himanshu.madhani@oracle.com>67Description:68 [RO] A device may need to internally split an atomic write I/O69 which straddles a given logical block address boundary. This70 parameter specifies the size in bytes of the atomic boundary if71 one is reported by the device. This value must be a72 power-of-two and at least the size as in73 atomic_write_unit_max_bytes.74 Any attempt to merge atomic write I/Os must not result in a75 merged I/O which crosses this boundary (if any).76 77 78What: /sys/block/<disk>/diskseq79Date: February 202180Contact: Matteo Croce <mcroce@microsoft.com>81Description:82 The /sys/block/<disk>/diskseq files reports the disk83 sequence number, which is a monotonically increasing84 number assigned to every drive.85 Some devices, like the loop device, refresh such number86 every time the backing file is changed.87 The value type is 64 bit unsigned.88 89 90What: /sys/block/<disk>/inflight91Date: October 200992Contact: Jens Axboe <axboe@kernel.dk>, Nikanth Karthikesan <knikanth@suse.de>93Description:94 Reports the number of I/O requests currently in progress95 (pending / in flight) in a device driver. This can be less96 than the number of requests queued in the block device queue.97 The report contains 2 fields: one for read requests98 and one for write requests.99 The value type is unsigned int.100 Cf. Documentation/block/stat.rst which contains a single value for101 requests in flight.102 This is related to /sys/block/<disk>/queue/nr_requests103 and for SCSI device also its queue_depth.104 105 106What: /sys/block/<disk>/integrity/device_is_integrity_capable107Date: July 2014108Contact: Martin K. Petersen <martin.petersen@oracle.com>109Description:110 Indicates whether a storage device is capable of storing111 integrity metadata. Set if the device is T10 PI-capable.112 113 114What: /sys/block/<disk>/integrity/format115Date: June 2008116Contact: Martin K. Petersen <martin.petersen@oracle.com>117Description:118 Metadata format for integrity capable block device.119 E.g. T10-DIF-TYPE1-CRC.120 121 122What: /sys/block/<disk>/integrity/protection_interval_bytes123Date: July 2015124Contact: Martin K. Petersen <martin.petersen@oracle.com>125Description:126 Describes the number of data bytes which are protected127 by one integrity tuple. Typically the device's logical128 block size.129 130 131What: /sys/block/<disk>/integrity/read_verify132Date: June 2008133Contact: Martin K. Petersen <martin.petersen@oracle.com>134Description:135 Indicates whether the block layer should verify the136 integrity of read requests serviced by devices that137 support sending integrity metadata.138 139 140What: /sys/block/<disk>/integrity/tag_size141Date: June 2008142Contact: Martin K. Petersen <martin.petersen@oracle.com>143Description:144 Number of bytes of integrity tag space available per145 512 bytes of data.146 147 148What: /sys/block/<disk>/integrity/write_generate149Date: June 2008150Contact: Martin K. Petersen <martin.petersen@oracle.com>151Description:152 Indicates whether the block layer should automatically153 generate checksums for write requests bound for154 devices that support receiving integrity metadata.155 156 157What: /sys/block/<disk>/partscan158Date: May 2024159Contact: Christoph Hellwig <hch@lst.de>160Description:161 The /sys/block/<disk>/partscan files reports if partition162 scanning is enabled for the disk. It returns "1" if partition163 scanning is enabled, or "0" if not. The value type is a 32-bit164 unsigned integer, but only "0" and "1" are valid values.165 166 167What: /sys/block/<disk>/<partition>/alignment_offset168Date: April 2009169Contact: Martin K. Petersen <martin.petersen@oracle.com>170Description:171 Storage devices may report a physical block size that is172 bigger than the logical block size (for instance a drive173 with 4KB physical sectors exposing 512-byte logical174 blocks to the operating system). This parameter175 indicates how many bytes the beginning of the partition176 is offset from the disk's natural alignment.177 178 179What: /sys/block/<disk>/<partition>/discard_alignment180Date: May 2011181Contact: Martin K. Petersen <martin.petersen@oracle.com>182Description:183 Devices that support discard functionality may184 internally allocate space in units that are bigger than185 the exported logical block size. The discard_alignment186 parameter indicates how many bytes the beginning of the187 partition is offset from the internal allocation unit's188 natural alignment.189 190 191What: /sys/block/<disk>/<partition>/stat192Date: February 2008193Contact: Jerome Marchand <jmarchan@redhat.com>194Description:195 The /sys/block/<disk>/<partition>/stat files display the196 I/O statistics of partition <partition>. The format is the197 same as the format of /sys/block/<disk>/stat.198 199 200What: /sys/block/<disk>/queue/add_random201Date: June 2010202Contact: linux-block@vger.kernel.org203Description:204 [RW] This file allows to turn off the disk entropy contribution.205 Default value of this file is '1'(on).206 207 208What: /sys/block/<disk>/queue/chunk_sectors209Date: September 2016210Contact: Hannes Reinecke <hare@suse.com>211Description:212 [RO] chunk_sectors has different meaning depending on the type213 of the disk. For a RAID device (dm-raid), chunk_sectors214 indicates the size in 512B sectors of the RAID volume stripe215 segment. For a zoned block device, either host-aware or216 host-managed, chunk_sectors indicates the size in 512B sectors217 of the zones of the device, with the eventual exception of the218 last zone of the device which may be smaller.219 220 221What: /sys/block/<disk>/queue/crypto/222Date: February 2022223Contact: linux-block@vger.kernel.org224Description:225 The presence of this subdirectory of /sys/block/<disk>/queue/226 indicates that the device supports inline encryption. This227 subdirectory contains files which describe the inline encryption228 capabilities of the device. For more information about inline229 encryption, refer to Documentation/block/inline-encryption.rst.230 231 232What: /sys/block/<disk>/queue/crypto/max_dun_bits233Date: February 2022234Contact: linux-block@vger.kernel.org235Description:236 [RO] This file shows the maximum length, in bits, of data unit237 numbers accepted by the device in inline encryption requests.238 239 240What: /sys/block/<disk>/queue/crypto/modes/<mode>241Date: February 2022242Contact: linux-block@vger.kernel.org243Description:244 [RO] For each crypto mode (i.e., encryption/decryption245 algorithm) the device supports with inline encryption, a file246 will exist at this location. It will contain a hexadecimal247 number that is a bitmask of the supported data unit sizes, in248 bytes, for that crypto mode.249 250 Currently, the crypto modes that may be supported are:251 252 * AES-256-XTS253 * AES-128-CBC-ESSIV254 * Adiantum255 256 For example, if a device supports AES-256-XTS inline encryption257 with data unit sizes of 512 and 4096 bytes, the file258 /sys/block/<disk>/queue/crypto/modes/AES-256-XTS will exist and259 will contain "0x1200".260 261 262What: /sys/block/<disk>/queue/crypto/num_keyslots263Date: February 2022264Contact: linux-block@vger.kernel.org265Description:266 [RO] This file shows the number of keyslots the device has for267 use with inline encryption.268 269 270What: /sys/block/<disk>/queue/dax271Date: June 2016272Contact: linux-block@vger.kernel.org273Description:274 [RO] This file indicates whether the device supports Direct275 Access (DAX), used by CPU-addressable storage to bypass the276 pagecache. It shows '1' if true, '0' if not.277 278 279What: /sys/block/<disk>/queue/discard_granularity280Date: May 2011281Contact: Martin K. Petersen <martin.petersen@oracle.com>282Description:283 [RO] Devices that support discard functionality may internally284 allocate space using units that are bigger than the logical285 block size. The discard_granularity parameter indicates the size286 of the internal allocation unit in bytes if reported by the287 device. Otherwise the discard_granularity will be set to match288 the device's physical block size. A discard_granularity of 0289 means that the device does not support discard functionality.290 291 292What: /sys/block/<disk>/queue/discard_max_bytes293Date: May 2011294Contact: Martin K. Petersen <martin.petersen@oracle.com>295Description:296 [RW] While discard_max_hw_bytes is the hardware limit for the297 device, this setting is the software limit. Some devices exhibit298 large latencies when large discards are issued, setting this299 value lower will make Linux issue smaller discards and300 potentially help reduce latencies induced by large discard301 operations.302 303 304What: /sys/block/<disk>/queue/discard_max_hw_bytes305Date: July 2015306Contact: linux-block@vger.kernel.org307Description:308 [RO] Devices that support discard functionality may have309 internal limits on the number of bytes that can be trimmed or310 unmapped in a single operation. The `discard_max_hw_bytes`311 parameter is set by the device driver to the maximum number of312 bytes that can be discarded in a single operation. Discard313 requests issued to the device must not exceed this limit. A314 `discard_max_hw_bytes` value of 0 means that the device does not315 support discard functionality.316 317 318What: /sys/block/<disk>/queue/discard_zeroes_data319Date: May 2011320Contact: Martin K. Petersen <martin.petersen@oracle.com>321Description:322 [RO] Will always return 0. Don't rely on any specific behavior323 for discards, and don't read this file.324 325 326What: /sys/block/<disk>/queue/dma_alignment327Date: May 2022328Contact: linux-block@vger.kernel.org329Description:330 Reports the alignment that user space addresses must have to be331 used for raw block device access with O_DIRECT and other driver332 specific passthrough mechanisms.333 334 335What: /sys/block/<disk>/queue/fua336Date: May 2018337Contact: linux-block@vger.kernel.org338Description:339 [RO] Whether or not the block driver supports the FUA flag for340 write requests. FUA stands for Force Unit Access. If the FUA341 flag is set that means that write requests must bypass the342 volatile cache of the storage device.343 344 345What: /sys/block/<disk>/queue/hw_sector_size346Date: January 2008347Contact: linux-block@vger.kernel.org348Description:349 [RO] This is the hardware sector size of the device, in bytes.350 351 352What: /sys/block/<disk>/queue/independent_access_ranges/353Date: October 2021354Contact: linux-block@vger.kernel.org355Description:356 [RO] The presence of this sub-directory of the357 /sys/block/xxx/queue/ directory indicates that the device is358 capable of executing requests targeting different sector ranges359 in parallel. For instance, single LUN multi-actuator hard-disks360 will have an independent_access_ranges directory if the device361 correctly advertises the sector ranges of its actuators.362 363 The independent_access_ranges directory contains one directory364 per access range, with each range described using the sector365 (RO) attribute file to indicate the first sector of the range366 and the nr_sectors (RO) attribute file to indicate the total367 number of sectors in the range starting from the first sector of368 the range. For example, a dual-actuator hard-disk will have the369 following independent_access_ranges entries.::370 371 $ tree /sys/block/<disk>/queue/independent_access_ranges/372 /sys/block/<disk>/queue/independent_access_ranges/373 |-- 0374 | |-- nr_sectors375 | `-- sector376 `-- 1377 |-- nr_sectors378 `-- sector379 380 The sector and nr_sectors attributes use 512B sector unit,381 regardless of the actual block size of the device. Independent382 access ranges do not overlap and include all sectors within the383 device capacity. The access ranges are numbered in increasing384 order of the range start sector, that is, the sector attribute385 of range 0 always has the value 0.386 387 388What: /sys/block/<disk>/queue/io_poll389Date: November 2015390Contact: linux-block@vger.kernel.org391Description:392 [RW] When read, this file shows whether polling is enabled (1)393 or disabled (0). Writing '0' to this file will disable polling394 for this device. Writing any non-zero value will enable this395 feature.396 397 398What: /sys/block/<disk>/queue/io_poll_delay399Date: November 2016400Contact: linux-block@vger.kernel.org401Description:402 [RW] This was used to control what kind of polling will be403 performed. It is now fixed to -1, which is classic polling.404 In this mode, the CPU will repeatedly ask for completions405 without giving up any time.406 <deprecated>407 408 409What: /sys/block/<disk>/queue/io_timeout410Date: November 2018411Contact: Weiping Zhang <zhangweiping@didiglobal.com>412Description:413 [RW] io_timeout is the request timeout in milliseconds. If a414 request does not complete in this time then the block driver415 timeout handler is invoked. That timeout handler can decide to416 retry the request, to fail it or to start a device recovery417 strategy.418 419 420What: /sys/block/<disk>/queue/iostats421Date: January 2009422Contact: linux-block@vger.kernel.org423Description:424 [RW] This file is used to control (on/off) the iostats425 accounting of the disk.426 427 428What: /sys/block/<disk>/queue/logical_block_size429Date: May 2009430Contact: Martin K. Petersen <martin.petersen@oracle.com>431Description:432 [RO] This is the smallest unit the storage device can address.433 It is typically 512 bytes.434 435 436What: /sys/block/<disk>/queue/max_active_zones437Date: July 2020438Contact: Niklas Cassel <niklas.cassel@wdc.com>439Description:440 [RO] For zoned block devices (zoned attribute indicating441 "host-managed" or "host-aware"), the sum of zones belonging to442 any of the zone states: EXPLICIT OPEN, IMPLICIT OPEN or CLOSED,443 is limited by this value. If this value is 0, there is no limit.444 445 If the host attempts to exceed this limit, the driver should446 report this error with BLK_STS_ZONE_ACTIVE_RESOURCE, which user447 space may see as the EOVERFLOW errno.448 449 450What: /sys/block/<disk>/queue/max_discard_segments451Date: February 2017452Contact: linux-block@vger.kernel.org453Description:454 [RO] The maximum number of DMA scatter/gather entries in a455 discard request.456 457 458What: /sys/block/<disk>/queue/max_hw_sectors_kb459Date: September 2004460Contact: linux-block@vger.kernel.org461Description:462 [RO] This is the maximum number of kilobytes supported in a463 single data transfer.464 465 466What: /sys/block/<disk>/queue/max_integrity_segments467Date: September 2010468Contact: linux-block@vger.kernel.org469Description:470 [RO] Maximum number of elements in a DMA scatter/gather list471 with integrity data that will be submitted by the block layer472 core to the associated block driver.473 474 475What: /sys/block/<disk>/queue/max_open_zones476Date: July 2020477Contact: Niklas Cassel <niklas.cassel@wdc.com>478Description:479 [RO] For zoned block devices (zoned attribute indicating480 "host-managed" or "host-aware"), the sum of zones belonging to481 any of the zone states: EXPLICIT OPEN or IMPLICIT OPEN, is482 limited by this value. If this value is 0, there is no limit.483 484 485What: /sys/block/<disk>/queue/max_sectors_kb486Date: September 2004487Contact: linux-block@vger.kernel.org488Description:489 [RW] This is the maximum number of kilobytes that the block490 layer will allow for a filesystem request. Must be smaller than491 or equal to the maximum size allowed by the hardware. Write 0492 to use default kernel settings.493 494 495What: /sys/block/<disk>/queue/max_segment_size496Date: March 2010497Contact: linux-block@vger.kernel.org498Description:499 [RO] Maximum size in bytes of a single element in a DMA500 scatter/gather list.501 502 503What: /sys/block/<disk>/queue/max_segments504Date: March 2010505Contact: linux-block@vger.kernel.org506Description:507 [RO] Maximum number of elements in a DMA scatter/gather list508 that is submitted to the associated block driver.509 510 511What: /sys/block/<disk>/queue/minimum_io_size512Date: April 2009513Contact: Martin K. Petersen <martin.petersen@oracle.com>514Description:515 [RO] Storage devices may report a granularity or preferred516 minimum I/O size which is the smallest request the device can517 perform without incurring a performance penalty. For disk518 drives this is often the physical block size. For RAID arrays519 it is often the stripe chunk size. A properly aligned multiple520 of minimum_io_size is the preferred request size for workloads521 where a high number of I/O operations is desired.522 523 524What: /sys/block/<disk>/queue/nomerges525Date: January 2010526Contact: linux-block@vger.kernel.org527Description:528 [RW] Standard I/O elevator operations include attempts to merge529 contiguous I/Os. For known random I/O loads these attempts will530 always fail and result in extra cycles being spent in the531 kernel. This allows one to turn off this behavior on one of two532 ways: When set to 1, complex merge checks are disabled, but the533 simple one-shot merges with the previous I/O request are534 enabled. When set to 2, all merge tries are disabled. The535 default value is 0 - which enables all types of merge tries.536 537 538What: /sys/block/<disk>/queue/nr_requests539Date: July 2003540Contact: linux-block@vger.kernel.org541Description:542 [RW] This controls how many requests may be allocated in the543 block layer for read or write requests. Note that the total544 allocated number may be twice this amount, since it applies only545 to reads or writes (not the accumulated sum).546 547 To avoid priority inversion through request starvation, a548 request queue maintains a separate request pool per each cgroup549 when CONFIG_BLK_CGROUP is enabled, and this parameter applies to550 each such per-block-cgroup request pool. IOW, if there are N551 block cgroups, each request queue may have up to N request552 pools, each independently regulated by nr_requests.553 554 555What: /sys/block/<disk>/queue/nr_zones556Date: November 2018557Contact: Damien Le Moal <damien.lemoal@wdc.com>558Description:559 [RO] nr_zones indicates the total number of zones of a zoned560 block device ("host-aware" or "host-managed" zone model). For561 regular block devices, the value is always 0.562 563 564What: /sys/block/<disk>/queue/optimal_io_size565Date: April 2009566Contact: Martin K. Petersen <martin.petersen@oracle.com>567Description:568 [RO] Storage devices may report an optimal I/O size, which is569 the device's preferred unit for sustained I/O. This is rarely570 reported for disk drives. For RAID arrays it is usually the571 stripe width or the internal track size. A properly aligned572 multiple of optimal_io_size is the preferred request size for573 workloads where sustained throughput is desired. If no optimal574 I/O size is reported this file contains 0.575 576 577What: /sys/block/<disk>/queue/physical_block_size578Date: May 2009579Contact: Martin K. Petersen <martin.petersen@oracle.com>580Description:581 [RO] This is the smallest unit a physical storage device can582 write atomically. It is usually the same as the logical block583 size but may be bigger. One example is SATA drives with 4KB584 sectors that expose a 512-byte logical block size to the585 operating system. For stacked block devices the586 physical_block_size variable contains the maximum587 physical_block_size of the component devices.588 589 590What: /sys/block/<disk>/queue/read_ahead_kb591Date: May 2004592Contact: linux-block@vger.kernel.org593Description:594 [RW] Maximum number of kilobytes to read-ahead for filesystems595 on this block device.596 597 For MADV_HUGEPAGE, the readahead size may exceed this setting598 since its granularity is based on the hugepage size.599 600 601What: /sys/block/<disk>/queue/rotational602Date: January 2009603Contact: linux-block@vger.kernel.org604Description:605 [RW] This file is used to stat if the device is of rotational606 type or non-rotational type.607 608 609What: /sys/block/<disk>/queue/rq_affinity610Date: September 2008611Contact: linux-block@vger.kernel.org612Description:613 [RW] If this option is '1', the block layer will migrate request614 completions to the cpu "group" that originally submitted the615 request. For some workloads this provides a significant616 reduction in CPU cycles due to caching effects.617 618 For storage configurations that need to maximize distribution of619 completion processing setting this option to '2' forces the620 completion to run on the requesting cpu (bypassing the "group"621 aggregation logic).622 623 624What: /sys/block/<disk>/queue/scheduler625Date: October 2004626Contact: linux-block@vger.kernel.org627Description:628 [RW] When read, this file will display the current and available629 IO schedulers for this block device. The currently active IO630 scheduler will be enclosed in [] brackets. Writing an IO631 scheduler name to this file will switch control of this block632 device to that new IO scheduler. Note that writing an IO633 scheduler name to this file will attempt to load that IO634 scheduler module, if it isn't already present in the system.635 636 637What: /sys/block/<disk>/queue/stable_writes638Date: September 2020639Contact: linux-block@vger.kernel.org640Description:641 [RW] This file will contain '1' if memory must not be modified642 while it is being used in a write request to this device. When643 this is the case and the kernel is performing writeback of a644 page, the kernel will wait for writeback to complete before645 allowing the page to be modified again, rather than allowing646 immediate modification as is normally the case. This647 restriction arises when the device accesses the memory multiple648 times where the same data must be seen every time -- for649 example, once to calculate a checksum and once to actually write650 the data. If no such restriction exists, this file will contain651 '0'. This file is writable for testing purposes.652 653What: /sys/block/<disk>/queue/virt_boundary_mask654Date: April 2021655Contact: linux-block@vger.kernel.org656Description:657 [RO] This file shows the I/O segment memory alignment mask for658 the block device. I/O requests to this device will be split659 between segments wherever either the memory address of the end660 of the previous segment or the memory address of the beginning661 of the current segment is not aligned to virt_boundary_mask + 1662 bytes.663 664 665What: /sys/block/<disk>/queue/wbt_lat_usec666Date: November 2016667Contact: linux-block@vger.kernel.org668Description:669 [RW] If the device is registered for writeback throttling, then670 this file shows the target minimum read latency. If this latency671 is exceeded in a given window of time (see wb_window_usec), then672 the writeback throttling will start scaling back writes. Writing673 a value of '0' to this file disables the feature. Writing a674 value of '-1' to this file resets the value to the default675 setting.676 677 678What: /sys/block/<disk>/queue/write_cache679Date: April 2016680Contact: linux-block@vger.kernel.org681Description:682 [RW] When read, this file will display whether the device has683 write back caching enabled or not. It will return "write back"684 for the former case, and "write through" for the latter. Writing685 to this file can change the kernels view of the device, but it686 doesn't alter the device state. This means that it might not be687 safe to toggle the setting from "write back" to "write through",688 since that will also eliminate cache flushes issued by the689 kernel.690 691 692What: /sys/block/<disk>/queue/write_same_max_bytes693Date: January 2012694Contact: Martin K. Petersen <martin.petersen@oracle.com>695Description:696 [RO] Some devices support a write same operation in which a697 single data block can be written to a range of several698 contiguous blocks on storage. This can be used to wipe areas on699 disk or to initialize drives in a RAID configuration.700 write_same_max_bytes indicates how many bytes can be written in701 a single write same command. If write_same_max_bytes is 0, write702 same is not supported by the device.703 704 705What: /sys/block/<disk>/queue/write_zeroes_max_bytes706Date: November 2016707Contact: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>708Description:709 [RO] Devices that support write zeroes operation in which a710 single request can be issued to zero out the range of contiguous711 blocks on storage without having any payload in the request.712 This can be used to optimize writing zeroes to the devices.713 write_zeroes_max_bytes indicates how many bytes can be written714 in a single write zeroes command. If write_zeroes_max_bytes is715 0, write zeroes is not supported by the device.716 717 718What: /sys/block/<disk>/queue/zone_append_max_bytes719Date: May 2020720Contact: linux-block@vger.kernel.org721Description:722 [RO] This is the maximum number of bytes that can be written to723 a sequential zone of a zoned block device using a zone append724 write operation (REQ_OP_ZONE_APPEND). This value is always 0 for725 regular block devices.726 727 728What: /sys/block/<disk>/queue/zone_write_granularity729Date: January 2021730Contact: linux-block@vger.kernel.org731Description:732 [RO] This indicates the alignment constraint, in bytes, for733 write operations in sequential zones of zoned block devices734 (devices with a zoned attributed that reports "host-managed" or735 "host-aware"). This value is always 0 for regular block devices.736 737 738What: /sys/block/<disk>/queue/zoned739Date: September 2016740Contact: Damien Le Moal <damien.lemoal@wdc.com>741Description:742 [RO] zoned indicates if the device is a zoned block device and743 the zone model of the device if it is indeed zoned. The744 possible values indicated by zoned are "none" for regular block745 devices and "host-aware" or "host-managed" for zoned block746 devices. The characteristics of host-aware and host-managed747 zoned block devices are described in the ZBC (Zoned Block748 Commands) and ZAC (Zoned Device ATA Command Set) standards.749 These standards also define the "drive-managed" zone model.750 However, since drive-managed zoned block devices do not support751 zone commands, they will be treated as regular block devices and752 zoned will report "none".753 754 755What: /sys/block/<disk>/hidden756Date: March 2023757Contact: linux-block@vger.kernel.org758Description:759 [RO] the block device is hidden. it doesn’t produce events, and760 can’t be opened from userspace or using blkdev_get*.761 Used for the underlying components of multipath devices.762 763 764What: /sys/block/<disk>/stat765Date: February 2008766Contact: Jerome Marchand <jmarchan@redhat.com>767Description:768 The /sys/block/<disk>/stat files displays the I/O769 statistics of disk <disk>. They contain 11 fields:770 771 == ==============================================772 1 reads completed successfully773 2 reads merged774 3 sectors read775 4 time spent reading (ms)776 5 writes completed777 6 writes merged778 7 sectors written779 8 time spent writing (ms)780 9 I/Os currently in progress781 10 time spent doing I/Os (ms)782 11 weighted time spent doing I/Os (ms)783 12 discards completed784 13 discards merged785 14 sectors discarded786 15 time spent discarding (ms)787 16 flush requests completed788 17 time spent flushing (ms)789 == ==============================================790 791 For more details refer Documentation/admin-guide/iostats.rst792