• Home
  • History
  • Annotate
  • Line#
  • Navigate
  • Raw
  • Download
  • only in /asuswrt-rt-n18u-9.0.0.4.380.2695/release/src-rt-6.x.4708/linux/linux-2.6/Documentation/ABI/testing/
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.
145