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/device_is_integrity_capable
57Date:		July 2014
58Contact:	Martin K. Petersen <martin.petersen@oracle.com>
59Description:
60		Indicates whether a storage device is capable of storing
61		integrity metadata. Set if the device is T10 PI-capable.
62
63What:		/sys/block/<disk>/integrity/protection_interval_bytes
64Date:		July 2015
65Contact:	Martin K. Petersen <martin.petersen@oracle.com>
66Description:
67		Describes the number of data bytes which are protected
68		by one integrity tuple. Typically the device's logical
69		block size.
70
71What:		/sys/block/<disk>/integrity/write_generate
72Date:		June 2008
73Contact:	Martin K. Petersen <martin.petersen@oracle.com>
74Description:
75		Indicates whether the block layer should automatically
76		generate checksums for write requests bound for
77		devices that support receiving integrity metadata.
78
79What:		/sys/block/<disk>/alignment_offset
80Date:		April 2009
81Contact:	Martin K. Petersen <martin.petersen@oracle.com>
82Description:
83		Storage devices may report a physical block size that is
84		bigger than the logical block size (for instance a drive
85		with 4KB physical sectors exposing 512-byte logical
86		blocks to the operating system).  This parameter
87		indicates how many bytes the beginning of the device is
88		offset from the disk's natural alignment.
89
90What:		/sys/block/<disk>/<partition>/alignment_offset
91Date:		April 2009
92Contact:	Martin K. Petersen <martin.petersen@oracle.com>
93Description:
94		Storage devices may report a physical block size that is
95		bigger than the logical block size (for instance a drive
96		with 4KB physical sectors exposing 512-byte logical
97		blocks to the operating system).  This parameter
98		indicates how many bytes the beginning of the partition
99		is offset from the disk's natural alignment.
100
101What:		/sys/block/<disk>/queue/logical_block_size
102Date:		May 2009
103Contact:	Martin K. Petersen <martin.petersen@oracle.com>
104Description:
105		This is the smallest unit the storage device can
106		address.  It is typically 512 bytes.
107
108What:		/sys/block/<disk>/queue/physical_block_size
109Date:		May 2009
110Contact:	Martin K. Petersen <martin.petersen@oracle.com>
111Description:
112		This is the smallest unit a physical storage device can
113		write atomically.  It is usually the same as the logical
114		block size but may be bigger.  One example is SATA
115		drives with 4KB sectors that expose a 512-byte logical
116		block size to the operating system.  For stacked block
117		devices the physical_block_size variable contains the
118		maximum physical_block_size of the component devices.
119
120What:		/sys/block/<disk>/queue/minimum_io_size
121Date:		April 2009
122Contact:	Martin K. Petersen <martin.petersen@oracle.com>
123Description:
124		Storage devices may report a granularity or preferred
125		minimum I/O size which is the smallest request the
126		device can perform without incurring a performance
127		penalty.  For disk drives this is often the physical
128		block size.  For RAID arrays it is often the stripe
129		chunk size.  A properly aligned multiple of
130		minimum_io_size is the preferred request size for
131		workloads where a high number of I/O operations is
132		desired.
133
134What:		/sys/block/<disk>/queue/optimal_io_size
135Date:		April 2009
136Contact:	Martin K. Petersen <martin.petersen@oracle.com>
137Description:
138		Storage devices may report an optimal I/O size, which is
139		the device's preferred unit for sustained I/O.  This is
140		rarely reported for disk drives.  For RAID arrays it is
141		usually the stripe width or the internal track size.  A
142		properly aligned multiple of optimal_io_size is the
143		preferred request size for workloads where sustained
144		throughput is desired.  If no optimal I/O size is
145		reported this file contains 0.
146
147What:		/sys/block/<disk>/queue/nomerges
148Date:		January 2010
149Contact:
150Description:
151		Standard I/O elevator operations include attempts to
152		merge contiguous I/Os. For known random I/O loads these
153		attempts will always fail and result in extra cycles
154		being spent in the kernel. This allows one to turn off
155		this behavior on one of two ways: When set to 1, complex
156		merge checks are disabled, but the simple one-shot merges
157		with the previous I/O request are enabled. When set to 2,
158		all merge tries are disabled. The default value is 0 -
159		which enables all types of merge tries.
160
161What:		/sys/block/<disk>/discard_alignment
162Date:		May 2011
163Contact:	Martin K. Petersen <martin.petersen@oracle.com>
164Description:
165		Devices that support discard functionality may
166		internally allocate space in units that are bigger than
167		the exported logical block size. The discard_alignment
168		parameter indicates how many bytes the beginning of the
169		device is offset from the internal allocation unit's
170		natural alignment.
171
172What:		/sys/block/<disk>/<partition>/discard_alignment
173Date:		May 2011
174Contact:	Martin K. Petersen <martin.petersen@oracle.com>
175Description:
176		Devices that support discard functionality may
177		internally allocate space in units that are bigger than
178		the exported logical block size. The discard_alignment
179		parameter indicates how many bytes the beginning of the
180		partition is offset from the internal allocation unit's
181		natural alignment.
182
183What:		/sys/block/<disk>/queue/discard_granularity
184Date:		May 2011
185Contact:	Martin K. Petersen <martin.petersen@oracle.com>
186Description:
187		Devices that support discard functionality may
188		internally allocate space using units that are bigger
189		than the logical block size. The discard_granularity
190		parameter indicates the size of the internal allocation
191		unit in bytes if reported by the device. Otherwise the
192		discard_granularity will be set to match the device's
193		physical block size. A discard_granularity of 0 means
194		that the device does not support discard functionality.
195
196What:		/sys/block/<disk>/queue/discard_max_bytes
197Date:		May 2011
198Contact:	Martin K. Petersen <martin.petersen@oracle.com>
199Description:
200		Devices that support discard functionality may have
201		internal limits on the number of bytes that can be
202		trimmed or unmapped in a single operation. Some storage
203		protocols also have inherent limits on the number of
204		blocks that can be described in a single command. The
205		discard_max_bytes parameter is set by the device driver
206		to the maximum number of bytes that can be discarded in
207		a single operation. Discard requests issued to the
208		device must not exceed this limit. A discard_max_bytes
209		value of 0 means that the device does not support
210		discard functionality.
211
212What:		/sys/block/<disk>/queue/discard_zeroes_data
213Date:		May 2011
214Contact:	Martin K. Petersen <martin.petersen@oracle.com>
215Description:
216		Devices that support discard functionality may return
217		stale or random data when a previously discarded block
218		is read back. This can cause problems if the filesystem
219		expects discarded blocks to be explicitly cleared. If a
220		device reports that it deterministically returns zeroes
221		when a discarded area is read the discard_zeroes_data
222		parameter will be set to one. Otherwise it will be 0 and
223		the result of reading a discarded area is undefined.
224
225What:		/sys/block/<disk>/queue/write_same_max_bytes
226Date:		January 2012
227Contact:	Martin K. Petersen <martin.petersen@oracle.com>
228Description:
229		Some devices support a write same operation in which a
230		single data block can be written to a range of several
231		contiguous blocks on storage. This can be used to wipe
232		areas on disk or to initialize drives in a RAID
233		configuration. write_same_max_bytes indicates how many
234		bytes can be written in a single write same command. If
235		write_same_max_bytes is 0, write same is not supported
236		by the device.
237
238