/Documentation/ABI/testing/sysfs-block

  1What:		/sys/block/<disk>/stat
  2Date:		February 2008
  3Contact:	Jerome Marchand <jmarchan@redhat.com>
  4Description:
  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
 21What:		/sys/block/<disk>/<part>/stat
 22Date:		February 2008
 23Contact:	Jerome Marchand <jmarchan@redhat.com>
 24Description:
 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
 31What:		/sys/block/<disk>/integrity/format
 32Date:		June 2008
 33Contact:	Martin K. Petersen <martin.petersen@oracle.com>
 34Description:
 35		Metadata format for integrity capable block device.
 36		E.g. T10-DIF-TYPE1-CRC.
 37
 38
 39What:		/sys/block/<disk>/integrity/read_verify
 40Date:		June 2008
 41Contact:	Martin K. Petersen <martin.petersen@oracle.com>
 42Description:
 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
 48What:		/sys/block/<disk>/integrity/tag_size
 49Date:		June 2008
 50Contact:	Martin K. Petersen <martin.petersen@oracle.com>
 51Description:
 52		Number of bytes of integrity tag space available per
 53		512 bytes of data.
 54
 55
 56What:		/sys/block/<disk>/integrity/write_generate
 57Date:		June 2008
 58Contact:	Martin K. Petersen <martin.petersen@oracle.com>
 59Description:
 60		Indicates whether the block layer should automatically
 61		generate checksums for write requests bound for
 62		devices that support receiving integrity metadata.
 63
 64What:		/sys/block/<disk>/alignment_offset
 65Date:		April 2009
 66Contact:	Martin K. Petersen <martin.petersen@oracle.com>
 67Description:
 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
 75What:		/sys/block/<disk>/<partition>/alignment_offset
 76Date:		April 2009
 77Contact:	Martin K. Petersen <martin.petersen@oracle.com>
 78Description:
 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
 86What:		/sys/block/<disk>/queue/logical_block_size
 87Date:		May 2009
 88Contact:	Martin K. Petersen <martin.petersen@oracle.com>
 89Description:
 90		This is the smallest unit the storage device can
 91		address.  It is typically 512 bytes.
 92
 93What:		/sys/block/<disk>/queue/physical_block_size
 94Date:		May 2009
 95Contact:	Martin K. Petersen <martin.petersen@oracle.com>
 96Description:
 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
105What:		/sys/block/<disk>/queue/minimum_io_size
106Date:		April 2009
107Contact:	Martin K. Petersen <martin.petersen@oracle.com>
108Description:
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
119What:		/sys/block/<disk>/queue/optimal_io_size
120Date:		April 2009
121Contact:	Martin K. Petersen <martin.petersen@oracle.com>
122Description:
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
132What:		/sys/block/<disk>/queue/nomerges
133Date:		January 2010
134Contact:
135Description:
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.