Bug 790902

Summary: Do not know how to create disk partitions
Product: Red Hat Enterprise Linux 6 Reporter: Konstantin Olchanski <olchansk>
Component: partedAssignee: Brian Lane <bcl>
Status: CLOSED NOTABUG QA Contact: Release Test Team <release-test-team>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1Keywords: Reopened
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-12 21:33:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Konstantin Olchanski 2012-02-15 17:16:32 UTC 
In the past, I have used "fdisk" to create disk partitions and all was good. Now I have 3TB disks that require the GPT partition table, not supported by fdisk & co. I am directed to use "gpart".

So I consult the RHEL documentation, which directs me to use the "gpart" "mkpart" command, but does not explain how to actually partition a disk:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-disk-storage-parted-create-part.html

I have these specific problems:
- the "print" command complains about "unrecognised disk label". This is a blank disk, so initial partition table needs to be created using "mklabel gpt". This should be documented.
- the "mkpart" command requires the "start" and "end" arguments, but the value of "start" for the first partition is not explained. If I use value "0", parted complains about "The resulting partition is not properly aligned for best performance", but does not suggest what value I should use. This needs to be documented.
- it is not clear how to create a partition spanning the whole 3TB disk. In addition to the problem with the "start" value, I do not know what "end" value to use. Too small values leave unused space at the end of the disk, too large values yield an error "The location 4000000 is outside of the device /dev/sdc". Is there a way to finding the correct "end" value other than by trial and error?
- I want to create 3 partitions - first partition is 40GB, second partition 30GB, third partition using the rest of the disk. How exactly do I do this? Specifically:
a) what value do I use for "start" of the first partition,
b) how do I specify that the second partition should start right after the first partition (without a gap) and be of correct size without having to use paper and pencil to do the math myself. How do I verify that I did the math correctly and did not create overlapping partitions or left a gap between them.
c) same for the 2nd partition
d) what is the "end" value for the last partition. Can I tell parted to create a partition from start of 2nd partition to the end of the disk?

These are a typical use cases for the parted tool and they need to be documented.

K.O.
Comment 2 Brian Lane 2012-02-15 18:47:12 UTC 
parted is fully documented in the INFO system. 'info parted', or just the commands in the manpage 'man parted'.

You can use units to specify your partition sizes, eg. 3TB, 40GB, etc. and parted will try to 'do the right thing' by snapping the endpoints to the closest partitions.
Comment 3 Konstantin Olchanski 2012-02-18 03:15:59 UTC 
I read "man parted" and "info parted". Neither answers any of my questions. There is no discussion of "start" and "end" parameters to the "mkpart" command (other that using "0" for "start" of first partition - as I just reported the RHEL6.1 parted does not like value "0" but does not offer an alternative). There is no examples whatsoever for the common cases - how to create a partition spanning the whole disk, or how to create a common layout with a boot/system partition, swap partition and data partition.

I also note that you mention parted "doing the right thing" and "snapping endpoints to ...", but I do not see any mention of these features in the documentation you pointed me to.

I do not think RH should be so dismissive of such glaring deficiencies in the documentation (and I suspect in the functionality) of an essencial tool that everybody will be soon forced to use.

K.O.