Red Hat Bugzilla – Bug 361951
Newer drives require specific layout of partitions for effiicency
Last modified: 2013-01-09 06:26:07 EST
Description of problem:
ATA7 introduced 1K sector sizes for physical media. ATA8 defines 1K and 4K
physical media sizes with arbitary permitted alignment. In order to get best
performance the OS must access the media in aligned sized chunks when writing.
The relevant information is all held in the drive identify data
For an ATA device
If word 106 has bits 15:14 = 01 it is valid.
bit 13 means logical sector size exceeds physical (assume 1K phys)
bit 12 means the physical sector size is > 512 bytes and the value is in word
bit 0-3 are the number of physical sectors per logical as a power of 2
117/118 hold the logical sector size
if 106 bit 13 is set then word 209 bit 15:14 should be 01 (if valid) and
bits 0-3 hold the offset of logical sector 0 within the physical sector (in
chunks of 512 bytes). For 4K media this will usually be 2560 bytes in (optimal
The partitioning tool needs to lay partitions out so that their start matches a
4K logical sector appropriately aligned if the drive is 4K, similarly for 1K
This is something that is being currently worked on upstream:
would wait for it to popup in fedora and then back port it, if necessary, when
the patch is nice and tested.
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.
Think this will be present in the next version of parted. Hopefully it will be released soon. Just needs some further testing.....
This will not go into rhel5 product (changing products). The patch in upstream has not been tested but should be on its way to f12. Might be something to think about for a minor release of rhel6
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
The code that handles the sector sizes that are not 512 bytes in size will not be included in f12. It is work that is currently being done in upstream and is not ready yet.
As stated in comment #8, Something that could be brought in for a minor release of rhel6.
*** Bug 510280 has been marked as a duplicate of this bug. ***
A few notes on the status of this, libparted has been patched (patches also send upstream), to export the alignment info which is now exported by the kernel
from 2.6.31 and later.
parted itself is not yet using this, but anaconda will use this information to create properly aligned partitions during installation.
I'm leaving this bug open to to track adding support to the parted cmdline binary for using the alignment info.
parted-1.9.0-24.el6's parted has a new --align= cmdline parameter, which
uses the new kernel topology info to create properly aligned partitions.
The default is --align=optimal, valid values are:
cylinder (the old behaviour)
Virtualization also requires alignment, since virtual disks are sometimes backed by files (which typically have at least 4k block alignment).
We need at least unconditional alignment to 4k, preferably more. Windows aligns to 1MB IIRC.
(In reply to comment #13)
> Virtualization also requires alignment, since virtual disks are sometimes
> backed by files (which typically have at least 4k block alignment).
> We need at least unconditional alignment to 4k, preferably more. Windows
> aligns to 1MB IIRC.
Then something needs to be done inside the virtualmachine / the kernel support for
the virtual disks, to make the alignment info show up in sysfs for these disks, once that is done, anaconda and parted will automatically pick this information up and use it.
Any hint on what that something might be?
I see /sys/block/sda/alignment_offset, but that's an offset, how do I specify the optimum alignment?
(In reply to comment #15)
> Any hint on what that something might be?
> I see /sys/block/sda/alignment_offset, but that's an offset, how do I specify
> the optimum alignment?
In your kernel source tree, parted checks for
And will align to optimal io size if possible, otherwise minimal io size if possible.
Ok. So calling blk_queue_physical_block_size() should suffice.
*** Bug 556473 has been marked as a duplicate of this bug. ***
can you give us some hints how should QE test this functionality?
If I understand correctly the fix for this bug is to support the --align parameter for parted so that anaconda can utilize the information from /sys and ask parted to create properly aligned partitions, is this correct?
(In reply to comment #20)
> Hi Hans,
> can you give us some hints how should QE test this functionality?
Erm, this is kinda tricky to test I'm afraid. You would need to have a machine which exports some sort of alignment information, which only the very latest and greatest (so called advanced format WD disks for example) do. Best thing is probably to buy such a disk for testing purposes for example the WD20EADS.
> If I understand correctly the fix for this bug is to support the --align
> parameter for parted so that anaconda can utilize the information from /sys and
> ask parted to create properly aligned partitions, is this correct?
More or less, we only use libparted not parted the cmdline tool, what we do is we ask the alignment requirements from libparted (which gets them from sysfs) and then create partitions based on those.
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.