Como posso mover, no local, a partição raiz de uma instância AWS t2.micro?

Question

Situação: Eu tenho o Ubuntu 14.04.5 configurado em uma instância AWS t2.micro usando o armazenamento SSD do EBS (a instância primária). Ao redimensionar com êxito a partição raiz de 8 GiB para 12 GiB, recebi o aviso: "A partição resultante não está corretamente alinhada para melhor desempenho". Eu pesquisei maneiras de resolver esse problema, mas nenhuma se ajustou aos meus requisitos para usar opções de linha de comando em uma instância secundária para modificar o volume interrompido e desconectado da instância primária (SOP para manipulação de instância do AWS).

O seguinte é editado em resposta à resposta de @ Michael.

Usando blkid e parted , encontrei essa configuração para a partição existente:

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
root@<domain>:~#

Depois de analisar várias fontes e [esta em particular,] link mostra que a configuração ideal desejada é:

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

Verificando mais minha configuração, encontrei as seguintes propriedades de E / S:

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

, o que indica que a partição não está alinhada de forma ideal e (conforme o post de referência mencionado) que o alinhamento ideal é de 1 MiB / 2048s.

Eu gostaria de usar parted (ou outras opções de linha de comando) para mover a partição, no local, de um início em 16065s para um início em 2048s, com o final da partição no final do disco, 25165823s. Isso pode ser feito como duas etapas; primeiro mova a partição sem alterar o tamanho, seguido por uma operação de redimensionamento. Ou, se possível, mova e redimensione em uma operação. É claro que eu faria um instantâneo da instância primária interrompida antes de fazer qualquer alteração, e usaria uma instância secundária para operar no sistema de partição / arquivo da instância primária.

Minhas perguntas são:

1. É possível usar o subcomando parted move para fazer isso? Se sim, como?

2. Há operações de limpeza necessárias para garantir que a partição alterada inicialize (depois de ser desanexada da instância secundária e reconectada corretamente à instância primária)?

3. Alguma outra sugestão para uma abordagem?

4. Por que o aviso é dado mesmo que a resposta de @ Michael indique que o alinhamento já é ótimo?

DVHirst

    

Answer 1

A mensagem parece (para mim) incorreta.

16065 é onde a partição raiz começa em instâncias lançadas a partir de AMIs oficiais do Ubuntu na 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

Dado que o volume de EBS reivindica 255 cabeças e 63 trilhas, 16065 parece estar no alinhamento teórico perfeito , como 63 × 255 = 16065 ... então supondo que minha matemática esteja correta, isso é o primeiro setor da primeira faixa no segundo cilindro - embora nenhuma dessa geometria seja real, já que o disco é um volume do EBS.

Eu estaria inclinado a deixar isso exatamente como está. Se estiver errado, parece que a Canonical e / ou a AWS têm algumas explicações a fazer, considerando os incontáveis milhões de instâncias exatamente com essa configuração.