What: /sys/block/<disk>/stat Date: February 2008 Contact: Jerome Marchand <jmarchan@redhat.com> Description: The /sys/block/<disk>/stat files displays the I/O statistics of disk <disk>. They contain 11 fields: 1 - reads completed successfully 2 - reads merged 3 - sectors read 4 - time spent reading (ms) 5 - writes completed 6 - writes merged 7 - sectors written 8 - time spent writing (ms) 9 - I/Os currently in progress 10 - time spent doing I/Os (ms) 11 - weighted time spent doing I/Os (ms) For more details refer Documentation/iostats.txt What: /sys/block/<disk>/<part>/stat Date: February 2008 Contact: Jerome Marchand <jmarchan@redhat.com> Description: The /sys/block/<disk>/<part>/stat files display the I/O statistics of partition <part>. The format is the same as the above-written /sys/block/<disk>/stat format. What: /sys/block/<disk>/integrity/format Date: June 2008 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Metadata format for integrity capable block device. E.g. T10-DIF-TYPE1-CRC. What: /sys/block/<disk>/integrity/read_verify Date: June 2008 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Indicates whether the block layer should verify the integrity of read requests serviced by devices that support sending integrity metadata. What: /sys/block/<disk>/integrity/tag_size Date: June 2008 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Number of bytes of integrity tag space available per 512 bytes of data. What: /sys/block/<disk>/integrity/write_generate Date: June 2008 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Indicates whether the block layer should automatically generate checksums for write requests bound for devices that support receiving integrity metadata. What: /sys/block/<disk>/alignment_offset Date: April 2009 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Storage devices may report a physical block size that is bigger than the logical block size (for instance a drive with 4KB physical sectors exposing 512-byte logical blocks to the operating system). This parameter indicates how many bytes the beginning of the device is offset from the disk's natural alignment. What: /sys/block/<disk>/<partition>/alignment_offset Date: April 2009 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Storage devices may report a physical block size that is bigger than the logical block size (for instance a drive with 4KB physical sectors exposing 512-byte logical blocks to the operating system). This parameter indicates how many bytes the beginning of the partition is offset from the disk's natural alignment. What: /sys/block/<disk>/queue/logical_block_size Date: May 2009 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: This is the smallest unit the storage device can address. It is typically 512 bytes. What: /sys/block/<disk>/queue/physical_block_size Date: May 2009 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: This is the smallest unit a physical storage device can write atomically. It is usually the same as the logical block size but may be bigger. One example is SATA drives with 4KB sectors that expose a 512-byte logical block size to the operating system. For stacked block devices the physical_block_size variable contains the maximum physical_block_size of the component devices. What: /sys/block/<disk>/queue/minimum_io_size Date: April 2009 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Storage devices may report a granularity or preferred minimum I/O size which is the smallest request the device can perform without incurring a performance penalty. For disk drives this is often the physical block size. For RAID arrays it is often the stripe chunk size. A properly aligned multiple of minimum_io_size is the preferred request size for workloads where a high number of I/O operations is desired. What: /sys/block/<disk>/queue/optimal_io_size Date: April 2009 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Storage devices may report an optimal I/O size, which is the device's preferred unit for sustained I/O. This is rarely reported for disk drives. For RAID arrays it is usually the stripe width or the internal track size. A properly aligned multiple of optimal_io_size is the preferred request size for workloads where sustained throughput is desired. If no optimal I/O size is reported this file contains 0. What: /sys/block/<disk>/queue/nomerges Date: January 2010 Contact: Description: Standard I/O elevator operations include attempts to merge contiguous I/Os. For known random I/O loads these attempts will always fail and result in extra cycles being spent in the kernel. This allows one to turn off this behavior on one of two ways: When set to 1, complex merge checks are disabled, but the simple one-shot merges with the previous I/O request are enabled. When set to 2, all merge tries are disabled. The default value is 0 - which enables all types of merge tries. What: /sys/block/<disk>/discard_alignment Date: May 2011 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Devices that support discard functionality may internally allocate space in units that are bigger than the exported logical block size. The discard_alignment parameter indicates how many bytes the beginning of the device is offset from the internal allocation unit's natural alignment. What: /sys/block/<disk>/<partition>/discard_alignment Date: May 2011 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Devices that support discard functionality may internally allocate space in units that are bigger than the exported logical block size. The discard_alignment parameter indicates how many bytes the beginning of the partition is offset from the internal allocation unit's natural alignment. What: /sys/block/<disk>/queue/discard_granularity Date: May 2011 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Devices that support discard functionality may internally allocate space using units that are bigger than the logical block size. The discard_granularity parameter indicates the size of the internal allocation unit in bytes if reported by the device. Otherwise the discard_granularity will be set to match the device's physical block size. A discard_granularity of 0 means that the device does not support discard functionality. What: /sys/block/<disk>/queue/discard_max_bytes Date: May 2011 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Devices that support discard functionality may have internal limits on the number of bytes that can be trimmed or unmapped in a single operation. Some storage protocols also have inherent limits on the number of blocks that can be described in a single command. The discard_max_bytes parameter is set by the device driver to the maximum number of bytes that can be discarded in a single operation. Discard requests issued to the device must not exceed this limit. A discard_max_bytes value of 0 means that the device does not support discard functionality. What: /sys/block/<disk>/queue/discard_zeroes_data Date: May 2011 Contact: Martin K. Petersen <martin.petersen@oracle.com> Description: Devices that support discard functionality may return stale or random data when a previously discarded block is read back. This can cause problems if the filesystem expects discarded blocks to be explicitly cleared. If a device reports that it deterministically returns zeroes when a discarded area is read the discard_zeroes_data parameter will be set to one. Otherwise it will be 0 and the result of reading a discarded area is undefined.