Red Hat Bugzilla – Bug 623268
Parted command improperly rounds 1GB partitions
Last modified: 2014-06-18 04:47:15 EDT
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).
Looks like this is also a problem with newer versions of parted. Tested on f14 using parted v2.3 with the same results.
*** Bug 682336 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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