Situation: I have Ubuntu 14.04.5 configured on an AWS t2.micro instance using EBS SSD store (the primary instance). While successfully resizing the root partition from 8 GiB to 12 GiB, I got the warning: "The resulting partition is not properly aligned for best performance." I've researched ways to resolve this problem, but none fit my requirements for using command line options in a secondary instance to modify the stopped and detached volume of the primary instance (SOP for AWS instance manipulation).

The following is edited in response to @Michael's answer.

Using blkid and parted, I found this configuration for my existing partition:

root@<domain>:~# blkid
/dev/xvda1: LABEL="cloudimg-rootfx" UUID="<uuid>" TYPE="ext4"
root@<domain>:~# parted
GNU Parted 2.3
Using /dev/xvda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 25165824s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number   Start    End         Size        Type      File system   Flags
 1       16065s   25165823s   25149759s   primary   ext4          boot
(parted) quit

After reviewing several sources and [this one in particular,] http://rainbow.chard.org/2013/01/30/how-to-align-partitions-for-best-performance-using-parted/ analysis shows the desired optimal configuration is:

Disk /dev/xvda: 25165824s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number   Start    End         Size        Type      File system   Flags
 1       2048s    25165823s   25163776s   primary   ext4          boot

Checking my configuration further, I found the following IO properties:

root@domain:/# cat /sys/block/xvda/queue/optimal_io_size 0
root@domain:/# cat /sys/block/xvda/queue/minimum_io_size 512
root@domain:/# cat /sys/block/xvda/alignment_offset 0
root@domain:/# cat /sys/block/xvda/queue/physical_block_size 512
root@domain:/# parted /dev/xvda
GNU Parted 2.3
Using /dev/xvda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) align-check minimal 1
1 aligned
(parted) align-check optimal 1
1 not aligned

which would indicate that the partition is not optimally aligned and (per the referenced blog post) that the optimal alignment is at 1 MiB / 2048s.

I would like to use parted (or other command line options) to move the partition, in place, from a start at 16065s to a start at 2048s, with the end of the partition at the end of the disk, 25165823s. This might be done as two steps; first move the partition without changing the size, followed by a resize operation. Or, if possible do the move and resize in one operation. Of course, I'd take a snapshot of the stopped primary instance before making any changes, and I'd use a secondary instance to operate on the partition / file system of the primary instance.

My questions are:

    1. Is it possible to use the parted move subcommand to do this? If yes, how?
    2. Are there cleanup operations needed to ensure the changed partition will boot (after being detached from the secondary instance and reattached, properly, to the primary instance)?
    3. Any other suggestions for an approach?
    4. Why is the warning given even though @Michael's answer indicates that the alignment is already optimal?



The message seems (to me) to be incorrect.

16065 is where the root partition starts on instances launched from official Ubuntu AMIs on AWS.

Disk /dev/xvda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders, total 16777216 sectors

    Device Boot      Start         End      Blocks   Id  System    
/dev/xvda1   *       16065    16771859     8377897+  83  Linux

Given that the EBS volume claims 255 heads and 63 tracks, 16065 would seem to be in perfect theoretical alignment, as 63 × 255 = 16065... so assuming my math is correct, this is the first sector of the first track on the second cylinder -- though none of that geometry is real, as the disk is an EBS volume.

I'd be inclined to leave this exactly as it is. If it's wrong, it seems like Canonical and/or AWS have some explaining to do, given the countless millions of instances with exactly this configuration.

  • I hear you, particularly your final paragraph; I, too, would like to see something from AWS on this topic. Just call me confused for now. – dvhirst Jun 1 '17 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.