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