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 597What: /sys/block/<disk>/queue/virt_boundary_mask 598Date: April 2021 599Contact: linux-block@vger.kernel.org 600Description: 601 [RO] This file shows the I/O segment memory alignment mask for 602 the block device. I/O requests to this device will be split 603 between segments wherever either the memory address of the end 604 of the previous segment or the memory address of the beginning 605 of the current segment is not aligned to virt_boundary_mask + 1 606 bytes. 607 608 609What: /sys/block/<disk>/queue/wbt_lat_usec 610Date: November 2016 611Contact: linux-block@vger.kernel.org 612Description: 613 [RW] If the device is registered for writeback throttling, then 614 this file shows the target minimum read latency. If this latency 615 is exceeded in a given window of time (see wb_window_usec), then 616 the writeback throttling will start scaling back writes. Writing 617 a value of '0' to this file disables the feature. Writing a 618 value of '-1' to this file resets the value to the default 619 setting. 620 621 622What: /sys/block/<disk>/queue/write_cache 623Date: April 2016 624Contact: linux-block@vger.kernel.org 625Description: 626 [RW] When read, this file will display whether the device has 627 write back caching enabled or not. It will return "write back" 628 for the former case, and "write through" for the latter. Writing 629 to this file can change the kernels view of the device, but it 630 doesn't alter the device state. This means that it might not be 631 safe to toggle the setting from "write back" to "write through", 632 since that will also eliminate cache flushes issued by the 633 kernel. 634 635 636What: /sys/block/<disk>/queue/write_same_max_bytes 637Date: January 2012 638Contact: Martin K. Petersen <martin.petersen@oracle.com> 639Description: 640 [RO] Some devices support a write same operation in which a 641 single data block can be written to a range of several 642 contiguous blocks on storage. This can be used to wipe areas on 643 disk or to initialize drives in a RAID configuration. 644 write_same_max_bytes indicates how many bytes can be written in 645 a single write same command. If write_same_max_bytes is 0, write 646 same is not supported by the device. 647 648 649What: /sys/block/<disk>/queue/write_zeroes_max_bytes 650Date: November 2016 651Contact: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> 652Description: 653 [RO] Devices that support write zeroes operation in which a 654 single request can be issued to zero out the range of contiguous 655 blocks on storage without having any payload in the request. 656 This can be used to optimize writing zeroes to the devices. 657 write_zeroes_max_bytes indicates how many bytes can be written 658 in a single write zeroes command. If write_zeroes_max_bytes is 659 0, write zeroes is not supported by the device. 660 661 662What: /sys/block/<disk>/queue/zone_append_max_bytes 663Date: May 2020 664Contact: linux-block@vger.kernel.org 665Description: 666 [RO] This is the maximum number of bytes that can be written to 667 a sequential zone of a zoned block device using a zone append 668 write operation (REQ_OP_ZONE_APPEND). This value is always 0 for 669 regular block devices. 670 671 672What: /sys/block/<disk>/queue/zone_write_granularity 673Date: January 2021 674Contact: linux-block@vger.kernel.org 675Description: 676 [RO] This indicates the alignment constraint, in bytes, for 677 write operations in sequential zones of zoned block devices 678 (devices with a zoned attributed that reports "host-managed" or 679 "host-aware"). This value is always 0 for regular block devices. 680 681 682What: /sys/block/<disk>/queue/zoned 683Date: September 2016 684Contact: Damien Le Moal <damien.lemoal@wdc.com> 685Description: 686 [RO] zoned indicates if the device is a zoned block device and 687 the zone model of the device if it is indeed zoned. The 688 possible values indicated by zoned are "none" for regular block 689 devices and "host-aware" or "host-managed" for zoned block 690 devices. The characteristics of host-aware and host-managed 691 zoned block devices are described in the ZBC (Zoned Block 692 Commands) and ZAC (Zoned Device ATA Command Set) standards. 693 These standards also define the "drive-managed" zone model. 694 However, since drive-managed zoned block devices do not support 695 zone commands, they will be treated as regular block devices and 696 zoned will report "none". 697 698 699What: /sys/block/<disk>/hidden 700Date: March 2023 701Contact: linux-block@vger.kernel.org 702Description: 703 [RO] the block device is hidden. it doesn’t produce events, and 704 can’t be opened from userspace or using blkdev_get*. 705 Used for the underlying components of multipath devices. 706 707 708What: /sys/block/<disk>/stat 709Date: February 2008 710Contact: Jerome Marchand <jmarchan@redhat.com> 711Description: 712 The /sys/block/<disk>/stat files displays the I/O 713 statistics of disk <disk>. They contain 11 fields: 714 715 == ============================================== 716 1 reads completed successfully 717 2 reads merged 718 3 sectors read 719 4 time spent reading (ms) 720 5 writes completed 721 6 writes merged 722 7 sectors written 723 8 time spent writing (ms) 724 9 I/Os currently in progress 725 10 time spent doing I/Os (ms) 726 11 weighted time spent doing I/Os (ms) 727 12 discards completed 728 13 discards merged 729 14 sectors discarded 730 15 time spent discarding (ms) 731 16 flush requests completed 732 17 time spent flushing (ms) 733 == ============================================== 734 735 For more details refer Documentation/admin-guide/iostats.rst 736