Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 623268

Summary: Parted command improperly rounds 1GB partitions
Product: Red Hat Enterprise Linux 5 Reporter: Casey Dahlin <cdahlin>
Component: partedAssignee: Brian Lane <bcl>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.5CC: atodorov, bubrown, hdegoede, jstodola, meyering, moshiro, vanhoof
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: parted-1.8.1-29 Doc Type: Bug Fix
Doc Text:
Prior to this update, parted incorrectly calculated the position of a new partition if the size of the partition was 1 or smaller (for example 1GB, 0.5GB). This was due to the snap_to_boundaries() function which rounded the endpoint of the partition down. As a result, an extremely small partition was created. The source code has been modified and defining units smaller than 1 is no longer allowed. The next smaller units should be used; fox example, 500MB instead of 0.5GB. The 0 value is still allowed when specifying the start of the device.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-21 05:43:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 668957, 719046, 726828    

Description Casey Dahlin 2010-08-11 18:24:50 UTC
Trying to create a 1GB partition on a gpt partition table at position 0 yields a much smaller partition.

# parted /dev/sde -s mkpart primary 0 1GB
Warning: The resulting partition is not properly aligned for best performance.

# parted /dev/sde -s print

Model: LSI MegaRAID SAS RMB (scsi)
Disk /dev/sde: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      17.4kB  17.9kB  0.51kB               primary

I've not tested with non gpt partition tables but the customer claims things work fine there.

the problem appears to arise in the snap_to_boundaries function within do_mkpart. It appears to always elect to round the endpoint of the partition down, and because the unit size is used to determine rounding precision we get a very small partition (also explains why specifying as 1000M instead of 1G works fine).

Comment 1 Brian Lane 2010-09-28 23:44:00 UTC
Looks like this is also a problem with newer versions of parted. Tested on f14 using parted v2.3 with the same results.

Comment 3 Brian Lane 2011-03-05 01:01:37 UTC
*** Bug 682336 has been marked as a duplicate of this bug. ***

Comment 6 Jim Meyering 2011-03-24 13:52:21 UTC
When you specify a partition start or end position using large units like MB, parted interprets that as meaning you are willing to accept the specified value +/- half of the unit size: 500KB in this case.  I found that "feature" to be a hindrance, so have just made an upstream change to how parted interprets an endpoint specified with an IEC binary suffix like MiB, GiB, TiB, etc:

    http://thread.gmane.org/gmane.comp.gnu.parted.bugs/10322/focus=10330

In the mean time (i.e, before parted-2.4), you may want to follow the advice in "info parted", which recommends using the "s" (sector) suffix to specify precisely where you would like each starting and ending sector.  When you use units of "s" (or "B" bytes), parted does not take liberties with your numbers.
So, for your example above, you would use e.g., (note that while the first mkpart use above uses "primary", that string ends up being used as a GPT partition name, so it can be something more descriptive):

  parted /dev/sde -s mkpart PART_NAME 34s $(echo 2^30|bc)B

Note that with GPT, you must leave the first 34 sectors for the primary header.

Here's an excerpt from "info parted":

  Parted will compute sensible ranges for the locations you specify
  (e.g. a range of +/- 500 MB when you specify the location in ``G'',
  and a range of +/- 500 KB when you specify the location in ``M'')
  and will select the nearest location in this range from the one you
  wrote that satisfies constraints from both the operation, the
  filesystem being worked on, the disk label, other partitions and so
  on.  Use the sector unit ``s'' to specify exact locations (if they
  do not satisfy all constraints, Parted will ask you for the nearest
  solution).  Note that negative numbers count back from the end of
  the disk, with ``-1s'' pointing to the last sector of the disk.

Comment 8 RHEL Program Management 2011-08-05 12:32:47 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 10 Eliska Slobodova 2011-09-20 12:40:13 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, parted incorrectly calculated the position of a new partition if the size of the partition was 1 or smaller (for example 1GB, 0.5GB). This was due to the snap_to_boundaries() function which rounded the endpoint of the partition down. As a result, an extremely small partition was created. The source code has been modified and defining units smaller than 1 is no longer allowed. The next smaller units should be used; fox example, 500MB instead of 0.5GB. The 0 value is still allowed when specifying the start of the device.

Comment 12 Jan Stodola 2011-12-07 16:04:55 UTC
Reproduced with parted-1.8.1-28.el5:

[root@localhost ~]# rpm -q parted
parted-1.8.1-28.el5
root@localhost ~]# parted /dev/hdb print

Model: QEMU HARDDISK (ide)
Disk /dev/hdb: 8480MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End  Size  File system  Name  Flags

Information: Don't forget to update /etc/fstab, if necessary.

[root@localhost ~]# parted /dev/hdb -s mkpart primary 0 1GB
[root@localhost ~]# parted /dev/hdb -s print

Model: QEMU HARDDISK (ide)
Disk /dev/hdb: 8480MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      17.4kB  17.9kB  0.51kB               primary

[root@localhost ~]#


Retested with parted-1.8.1-29.el5, newly created partition has correct size:

[root@localhost ~]# rpm -q parted
parted-1.8.1-29.el
[root@localhost ~]# parted /dev/hdb -s print

Model: QEMU HARDDISK (ide)
Disk /dev/hdb: 8480MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End  Size  File system  Name  Flags

[root@localhost ~]# parted /dev/hdb -s mkpart primary 0 1GB
[root@localhost ~]# parted /dev/hdb -s print

Model: QEMU HARDDISK (ide)
Disk /dev/hdb: 8480MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      17.4kB  1000MB  1000MB               primary

[root@localhost ~]#


Creating 1GB partition on a disk with msdos label:

[root@localhost ~]# parted /dev/hdb -s mkpart primary 0 1GB
[root@localhost ~]# parted /dev/hdb -s print

Model: QEMU HARDDISK (ide)
Disk /dev/hdb: 8480MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  1003MB  1003MB  primary

[root@localhost ~]#


Creating partitions with unit smaller than 1 is not allowed:

[root@localhost ~]# parted /dev/hdb -s mkpart primary 0 0.5GB
Error: Use a smaller unit instead of a value < 1


Moving to VERIFIED.

Comment 13 errata-xmlrpc 2012-02-21 05:43:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0192.html