Based on kernel version 3.3. Page generated on 2012-03-23 21:22 EST.
1 What: /sys/block/<disk>/stat 2 Date: February 2008 3 Contact: Jerome Marchand <jmarchan@redhat.com> 4 Description: 5 The /sys/block/<disk>/stat files displays the I/O 6 statistics of disk <disk>. They contain 11 fields: 7 1 - reads completed successfully 8 2 - reads merged 9 3 - sectors read 10 4 - time spent reading (ms) 11 5 - writes completed 12 6 - writes merged 13 7 - sectors written 14 8 - time spent writing (ms) 15 9 - I/Os currently in progress 16 10 - time spent doing I/Os (ms) 17 11 - weighted time spent doing I/Os (ms) 18 For more details refer Documentation/iostats.txt 19 20 21 What: /sys/block/<disk>/<part>/stat 22 Date: February 2008 23 Contact: Jerome Marchand <jmarchan@redhat.com> 24 Description: 25 The /sys/block/<disk>/<part>/stat files display the 26 I/O statistics of partition <part>. The format is the 27 same as the above-written /sys/block/<disk>/stat 28 format. 29 30 31 What: /sys/block/<disk>/integrity/format 32 Date: June 2008 33 Contact: Martin K. Petersen <martin.petersen@oracle.com> 34 Description: 35 Metadata format for integrity capable block device. 36 E.g. T10-DIF-TYPE1-CRC. 37 38 39 What: /sys/block/<disk>/integrity/read_verify 40 Date: June 2008 41 Contact: Martin K. Petersen <martin.petersen@oracle.com> 42 Description: 43 Indicates whether the block layer should verify the 44 integrity of read requests serviced by devices that 45 support sending integrity metadata. 46 47 48 What: /sys/block/<disk>/integrity/tag_size 49 Date: June 2008 50 Contact: Martin K. Petersen <martin.petersen@oracle.com> 51 Description: 52 Number of bytes of integrity tag space available per 53 512 bytes of data. 54 55 56 What: /sys/block/<disk>/integrity/write_generate 57 Date: June 2008 58 Contact: Martin K. Petersen <martin.petersen@oracle.com> 59 Description: 60 Indicates whether the block layer should automatically 61 generate checksums for write requests bound for 62 devices that support receiving integrity metadata. 63 64 What: /sys/block/<disk>/alignment_offset 65 Date: April 2009 66 Contact: Martin K. Petersen <martin.petersen@oracle.com> 67 Description: 68 Storage devices may report a physical block size that is 69 bigger than the logical block size (for instance a drive 70 with 4KB physical sectors exposing 512-byte logical 71 blocks to the operating system). This parameter 72 indicates how many bytes the beginning of the device is 73 offset from the disk's natural alignment. 74 75 What: /sys/block/<disk>/<partition>/alignment_offset 76 Date: April 2009 77 Contact: Martin K. Petersen <martin.petersen@oracle.com> 78 Description: 79 Storage devices may report a physical block size that is 80 bigger than the logical block size (for instance a drive 81 with 4KB physical sectors exposing 512-byte logical 82 blocks to the operating system). This parameter 83 indicates how many bytes the beginning of the partition 84 is offset from the disk's natural alignment. 85 86 What: /sys/block/<disk>/queue/logical_block_size 87 Date: May 2009 88 Contact: Martin K. Petersen <martin.petersen@oracle.com> 89 Description: 90 This is the smallest unit the storage device can 91 address. It is typically 512 bytes. 92 93 What: /sys/block/<disk>/queue/physical_block_size 94 Date: May 2009 95 Contact: Martin K. Petersen <martin.petersen@oracle.com> 96 Description: 97 This is the smallest unit a physical storage device can 98 write atomically. It is usually the same as the logical 99 block size but may be bigger. One example is SATA 100 drives with 4KB sectors that expose a 512-byte logical 101 block size to the operating system. For stacked block 102 devices the physical_block_size variable contains the 103 maximum physical_block_size of the component devices. 104 105 What: /sys/block/<disk>/queue/minimum_io_size 106 Date: April 2009 107 Contact: Martin K. Petersen <martin.petersen@oracle.com> 108 Description: 109 Storage devices may report a granularity or preferred 110 minimum I/O size which is the smallest request the 111 device can perform without incurring a performance 112 penalty. For disk drives this is often the physical 113 block size. For RAID arrays it is often the stripe 114 chunk size. A properly aligned multiple of 115 minimum_io_size is the preferred request size for 116 workloads where a high number of I/O operations is 117 desired. 118 119 What: /sys/block/<disk>/queue/optimal_io_size 120 Date: April 2009 121 Contact: Martin K. Petersen <martin.petersen@oracle.com> 122 Description: 123 Storage devices may report an optimal I/O size, which is 124 the device's preferred unit for sustained I/O. This is 125 rarely reported for disk drives. For RAID arrays it is 126 usually the stripe width or the internal track size. A 127 properly aligned multiple of optimal_io_size is the 128 preferred request size for workloads where sustained 129 throughput is desired. If no optimal I/O size is 130 reported this file contains 0. 131 132 What: /sys/block/<disk>/queue/nomerges 133 Date: January 2010 134 Contact: 135 Description: 136 Standard I/O elevator operations include attempts to 137 merge contiguous I/Os. For known random I/O loads these 138 attempts will always fail and result in extra cycles 139 being spent in the kernel. This allows one to turn off 140 this behavior on one of two ways: When set to 1, complex 141 merge checks are disabled, but the simple one-shot merges 142 with the previous I/O request are enabled. When set to 2, 143 all merge tries are disabled. The default value is 0 - 144 which enables all types of merge tries. 145 146 What: /sys/block/<disk>/discard_alignment 147 Date: May 2011 148 Contact: Martin K. Petersen <martin.petersen@oracle.com> 149 Description: 150 Devices that support discard functionality may 151 internally allocate space in units that are bigger than 152 the exported logical block size. The discard_alignment 153 parameter indicates how many bytes the beginning of the 154 device is offset from the internal allocation unit's 155 natural alignment. 156 157 What: /sys/block/<disk>/<partition>/discard_alignment 158 Date: May 2011 159 Contact: Martin K. Petersen <martin.petersen@oracle.com> 160 Description: 161 Devices that support discard functionality may 162 internally allocate space in units that are bigger than 163 the exported logical block size. The discard_alignment 164 parameter indicates how many bytes the beginning of the 165 partition is offset from the internal allocation unit's 166 natural alignment. 167 168 What: /sys/block/<disk>/queue/discard_granularity 169 Date: May 2011 170 Contact: Martin K. Petersen <martin.petersen@oracle.com> 171 Description: 172 Devices that support discard functionality may 173 internally allocate space using units that are bigger 174 than the logical block size. The discard_granularity 175 parameter indicates the size of the internal allocation 176 unit in bytes if reported by the device. Otherwise the 177 discard_granularity will be set to match the device's 178 physical block size. A discard_granularity of 0 means 179 that the device does not support discard functionality. 180 181 What: /sys/block/<disk>/queue/discard_max_bytes 182 Date: May 2011 183 Contact: Martin K. Petersen <martin.petersen@oracle.com> 184 Description: 185 Devices that support discard functionality may have 186 internal limits on the number of bytes that can be 187 trimmed or unmapped in a single operation. Some storage 188 protocols also have inherent limits on the number of 189 blocks that can be described in a single command. The 190 discard_max_bytes parameter is set by the device driver 191 to the maximum number of bytes that can be discarded in 192 a single operation. Discard requests issued to the 193 device must not exceed this limit. A discard_max_bytes 194 value of 0 means that the device does not support 195 discard functionality. 196 197 What: /sys/block/<disk>/queue/discard_zeroes_data 198 Date: May 2011 199 Contact: Martin K. Petersen <martin.petersen@oracle.com> 200 Description: 201 Devices that support discard functionality may return 202 stale or random data when a previously discarded block 203 is read back. This can cause problems if the filesystem 204 expects discarded blocks to be explicitly cleared. If a 205 device reports that it deterministically returns zeroes 206 when a discarded area is read the discard_zeroes_data 207 parameter will be set to one. Otherwise it will be 0 and 208 the result of reading a discarded area is undefined.