Bug 361951 - Newer drives require specific layout of partitions for effiicency
Newer drives require specific layout of partitions for effiicency
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: parted (Show other bugs)
6.0
All Linux
medium Severity low
: rc
: ---
Assigned To: Hans de Goede
Release Test Team
: Reopened
: 510280 556473 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-01 11:18 EDT by Alan Cox
Modified: 2013-01-09 06:26 EST (History)
7 users (show)

See Also:
Fixed In Version: parted-1.9.0-24.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-15 09:34:33 EST
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 Alan Cox 2007-11-01 11:18:43 EDT
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
117/118
  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
for Windows)

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
Comment 1 Joel Andres Granados 2008-06-17 05:06:28 EDT
This is something that is being currently worked on upstream:
http://lists.alioth.debian.org/pipermail/parted-devel/2007-June/001754.html,  I
would wait for it to popup in fedora and then back port it, if necessary, when
the patch is nice and tested.
Comment 2 RHEL Product and Program Management 2008-06-17 05:28:19 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 
Comment 5 Joel Andres Granados 2008-10-17 04:45:01 EDT
Think this will be present in the next version of parted.  Hopefully it will be released soon.  Just needs some further testing.....
Comment 7 Joel Andres Granados 2009-06-12 04:48:33 EDT
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
Comment 8 RHEL Product and Program Management 2009-06-15 16:57:11 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 9 Joel Andres Granados 2009-07-13 07:30:00 EDT
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.
Comment 10 Joel Andres Granados 2009-07-13 07:30:28 EDT
*** Bug 510280 has been marked as a duplicate of this bug. ***
Comment 11 Hans de Goede 2009-11-03 07:37:08 EST
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.
Comment 12 Hans de Goede 2009-12-18 05:31:30 EST
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:
none
cylinder (the old behaviour)
minimal
optimal
Comment 13 Avi Kivity 2009-12-27 07:40:40 EST
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.
Comment 14 Hans de Goede 2009-12-28 03:52:32 EST
(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.  

Hi,

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.

Regards,

Hans
Comment 15 Avi Kivity 2009-12-28 10:35:49 EST
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?
Comment 16 Hans de Goede 2009-12-29 04:25:24 EST
(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?  

See:

Documentation/ABI/testing/sysfs-block

In your kernel source tree, parted checks for
/sys/block/<disk>/queue/minimum_io_size
/sys/block/<disk>/queue/optimal_io_size

And will align to optimal io size if possible, otherwise minimal io size if possible.
Comment 17 Avi Kivity 2009-12-30 13:05:06 EST
Ok.  So calling blk_queue_physical_block_size() should suffice.
Comment 19 Hans de Goede 2010-01-18 10:39:56 EST
*** Bug 556473 has been marked as a duplicate of this bug. ***
Comment 20 Alexander Todorov 2010-05-03 06:36:05 EDT
Hi Hans,
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?
Comment 21 Hans de Goede 2010-06-30 09:14:15 EDT
(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.
Comment 23 releng-rhel@redhat.com 2010-11-15 09:34:33 EST
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.

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