mjhjmtu

I'm partitioning a non-SSD hard disk with parted because I want a GPT partition table.

parted /dev/sda mklabel gpt

Now, I'm trying to create the partitions correctly aligned so I use the following command to know where the first sector begins:

parted /dev/sda unit s p free

Disk /dev/sda: 488397168s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
 34s 488397134s 488397101s Free Space

We can see that it starts in sector 34 (that's the default when this partition table is used).

So, to create the first partition I tried:

parted /dev/sda mkpart primary 63s 127s

to align it on sector 64 since it's a multiple of 8 but it shows:

Warning: The resulting partition is not properly aligned for best performance.

The logical and physical sector sizes in my hard disk are both 512 bytes:

cat /sys/block/sda/queue/physical_block_size
512

cat /sys/block/sda/queue/logical_block_size 
512

How do I create partitions correctly aligned? What am I doing wrong?

In order to align partition with parted you can use --align option. Valid alignment types are:

• 
  none - Use the minimum alignment allowed by the disk type.


• 
  cylinder - Align partitions to cylinders.


• 
  minimal - Use minimum alignment as given by the disk topology information. This and the opt value will use layout information provided by the disk to align the logical partition table addresses to actual physical blocks on the disks. The min value is the minimum alignment needed to align the partition properly to physical blocks, which avoids performance degradation.


• 
  optimal Use optimum alignment as given by the disk topology information. This aligns to a multiple of the physical block size in a way that guarantees optimal performance.

Other useful tip is that you can set the size with percentages to get it aligned. Start at 0% and end at 100%. For example:

parted -a optimal /dev/sda mkpart primary 0% 4096MB

My solution has been to use gdisk which can perform partitions alignment automatically on a 2048 sectors (1024KiB) by default, although it can be changed in the expert menu.

From the Arch Wiki:

When creating a partition, parted might warn about improper partition alignment but does not hint about proper alignment. For example:

(parted) mkpart primary fat16 0 32M
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? 

The warning means the partition start is not aligned.

Enter Ignore to go ahead anyway, print the partition table in sectors to see where it starts, and remove/recreate the partition with the start sector rounded up to increasing powers of 2 until the warning stops. As one example, on a flash drive with 512B sectors, Parted wanted partitions to start on sectors that were a multiple of 2048, which is 1MB alignment.

Additionally, just above this section, they state that the more precise IEC binary units of KiB, MiB, GiB, etc., are acceptable for units as well as the less precise KB, MB, GB, etc.

Personally, my exact command that solved this was:

mkpart hd ext4 1024KiB 8470MB

It didn't complain, I guess it wanted 1MB alignments.

A minor correction. As I understand it, GPT disks don't have partition types anymore, they are all "primary". Command 'mkpart primary' doesn't create a primary partition like it does on msdos disks, it just creates a partition called primary. You can just as well use command

(parted) mkpart Parted-FUN! 21476MB 4000787MB
(parted) print
Model: ATA ST4000DM000-1F21 (scsi)
Disk /dev/sdf: 4000787MB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 1.05MB 17181MB 17180MB ext4 raid-var
 2 17181MB 21476MB 4295MB raid-swap
 3 21476MB 4000786MB 3979310MB Parted-FUN!

This may cause confusion if you try creating logical partitions, I know it did for me.

(parted) mkpart extended 21476MB 4000787MB
(parted) mkpart logical 21476MB 1000787MB
Warning: You requested a partition from 21476MB to 1000787MB.
The closest location we can manage is 4000786MB to 4000786MB.
Is this still acceptable to you?
Yes/No? Yes
(parted) print
Model: ATA ST4000DM000-1F21 (scsi)
Disk /dev/sdf: 4000787MB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number Start End Size File system Name Flags
 1 1.05MB 17181MB 17180MB ext4 raid-var
 2 17181MB 21476MB 4295MB raid-swap
 3 21476MB 4000786MB 3979310MB extended
 4 4000786MB 4000786MB 0.00MB logical

You can't create a partition called "logical" inside a partition called "extended".

The accepted answer by @lik shows how you can specify the preferred alignment. However, parted always uses that alignment for checking the resulting partition, but not always creates partitions with that alignment.

TL;DR: When 1MiB is the optimal alignment, specifying 0% will work for disks of 200MiB and bigger. For smaller disks or larger alignment, specifying 0G could work where 0% does not. See below about why.

Parted does try to satisfy the alignment constraints when creating a partition, but it also will not deviate from your requested values too much. What counts as "too much" depends on how you specified the postions.

When you specify a start (or end) position to the mkpart command, it internally generates a range of acceptable values. This range is centered on the value you specify, and extends equally on both sides by half the unit size you used (that's what I read from the code, the comments say one full unit size on both ends).

For example, when you specify "10M", it will try to use any position between 9.5M and 10.5M. The same goes for percentages, so if you specify 0% it will use any value between 0% and 0.5% (it does not go negative, obviously).

One exception is that when using power-of-two-units (such as KiB for 1024, as opposed to K for 1000) parted assumes you're trying to specify an exact position and only considers the exact value you specified.

Since optimal alignment typically seems to be 1MiB-aligned, the K and M units will often not have sufficient room to reach optimal alignment. Specifying positions in G should have plenty room, but % is usually also fine.

So, this is why 0% usually works, though even that has limits.