Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 607345 - Review comments on Storage Administration Guide - I/O Limits
Review comments on Storage Administration Guide - I/O Limits
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Storage_Admin_Guide (Show other bugs)
6.0
All Linux
medium Severity medium
: rc
: ---
Assigned To: Don Domingo
:
Depends On:
Blocks: 561593
  Show dependency treegraph
 
Reported: 2010-06-23 17:02 EDT by Tom Coughlan
Modified: 2010-06-30 18:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-30 18:44:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Coughlan 2010-06-23 17:02:42 EDT
The release note Bug 580851 - "4.1. Storage Input/Output Limits" is confusing

correctly indicates that the term "limits" is misleading - "sounds like more general meaning, such as the device size limits, and/or some kind of QoS feature".

To address this, we would like to change the phrase "I/O limits" to the more specific term "I/O Alignment and Size", and when the context is clear, "I/O Parameters". This should be done in both the release notes and in this document. 

I would suggest replacing the existing text at the beginning of Chapter 20 as follows:

Chapter 20. [NEW!] Storage Input/Output (I/O) Alignment and Size 

Recent enhancements to the SCSI and ATA standards allow storage devices to
indicate their preferred (and in some cases, required) I/O alignment and I/O
size. This information is particularly useful with newer disk drives that
increase the physical sector size from 512 byes to 4K bytes. This information
may also be beneficial for RAID devices, where the chunk size and stripe size
may impact performance. 

The Linux I/O stack has been enhanced to process vendor-provided I/O alignment and size information, allowing storage management tools (parted, lvm, mkfs.*, and the like) to optimize data placement and access. If a legacy device does not export I/O alignment and I/O size data, then the storage management tools will conservatively align I/O on a 4k (or larger power of 2) boundary. This will ensure that 4K-sector devices operate correctly even if they do not implement this feature.  

Note: As of this release, 4K sector devices are supported as data disks, not as boot disks. Boot support for 4K sector devices is planned for a later release.  

Refer to Section 20.2, “Userspace Access” to learn how to determine the information that the operating system obtained from the device. This data is subsequently used by the storage management tools to determine data placement.  

20.1. Parameters for Storage Access

The information that the operating system uses to determine I/O alignment and size is as follows: 

• physical_block_size - smallest internal unit the device can operate on
• logical_block_size - used externally to address a location on the device
• alignment_offset - the number of bytes the beginning of the Linux block device
  (partition/MD/LVM device) is offset from the underlying physical alignment
• minimum_io_size - device’s preferred minimum unit for random I/O
• optimal_io_size - device’s preferred unit for streaming I/O

As an example, certain 4K sector devices may use a 4K physical_block_size internally but expose a more granular 512-byte logical_block_size to Linux. This discrepancy introduces potential for misaligned I/O.
To address this, the Red Hat Enterprise Linux 6 I/O stack will attempt to start all data areas on a naturally aligned boundary (physical_block_size) by making sure it accounts for any alignment_offset if the beginning of the block device is offset from the underlying physical alignment.

Storage vendors can also supply I/O hints about the preferred minimum unit for random I/O (minimum_io_size) and streaming I/O (optimal_io_size) of a device. For example, minimum_io_size and optimal_io_size may correspond to a RAID device's chunk size and stripe size respectively. 


< For the remainder of Chapter 20, just replace "I/O limits" with "I/O parameters" throughout. >

Mike, please review.
Comment 1 RHEL Product and Program Management 2010-06-23 17:12:52 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 2 Don Domingo 2010-06-23 19:28:42 EDT
thanks Mike, Tom. I've updated the doc:

http://brisvegas.bne.redhat.com/rhel6-storageguide/index-single.html#newstorage-iolimits

please let me know if any further revisions are required.
Comment 3 Mike Snitzer 2010-06-23 20:49:08 EDT
(In reply to comment #2)
> thanks Mike, Tom. I've updated the doc:
> 
> http://brisvegas.bne.redhat.com/rhel6-storageguide/index-single.html#newstorage-iolimits
> 
> please let me know if any further revisions are required.    

I'm _really_ not a fan of s/limits/parameters/.  I think we seized on NEC's concern about "limits" way too aggressively but I'll accept it (as I'm quite biased being so close to these details.. I also worked harder than I'd care to have done to switch peoples' thinking from "topology" to "limits"!).

'limits' wasn't something out of left field.  Case in point the BLOCK LIMITS VPD page provides alignment and {physical,logical}_block_size information.  Also, the kernel's data structure where this info is stored is 'struct queue_limits'.

But, whatever... "parameters" it is.

Don, here are some Edit notes:

- s/frmo/from/ in the opening paragraph.

- in 19.6, we need to correct this:
"If a device doesn't provide I/O parameters information, fdisk will align all partitions on a 1MB boundary."
to be something like:
"fdisk will align all partitions on a 1MB boundary."
See this for more details: https://bugzilla.redhat.com/show_bug.cgi?id=179390#c60

- 19.6: "As such, by default all partitions will align on a 1MB boundary." should be:
"As such, by default all partitions will be aligned on a 1MB boundary."
Comment 4 Don Domingo 2010-06-23 21:22:50 EDT
thanks Mike. I've applied your revisions accordingly, and updated the test build.
Comment 5 Tom Coughlan 2010-06-23 22:15:28 EDT
(In reply to comment #3)

> 'limits' wasn't something out of left field.  Case in point the BLOCK LIMITS
> VPD page provides alignment and {physical,logical}_block_size information. 

From SBC-3:

6.5.3 Block Limits VPD page
The Block Limits VPD page provides the application client with the means to obtain certain operating parameters of the logical unit.
                         ----------

:)
Comment 6 Mike Snitzer 2010-06-24 02:31:41 EDT
(In reply to comment #5)
> (In reply to comment #3)
> 
> > 'limits' wasn't something out of left field.  Case in point the BLOCK LIMITS
> > VPD page provides alignment and {physical,logical}_block_size information. 
> 
> From SBC-3:
> 
> 6.5.3 Block Limits VPD page
> The Block Limits VPD page provides the application client with the means to
> obtain certain operating parameters of the logical unit.
>                          ----------
> 
> :)    

Well played sir...

Note You need to log in before you can comment on or make changes to this bug.