OpenCloudOS-Kernel/Documentation/ABI/testing/sysfs-block

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.