Dentro do EC2, para mim, só faz sentido usar todo o volume do sistema de arquivos, devido à flexibilidade permitida pelos volumes do Elastic Block Store (EBS), que são muito diferentes de muitos discos físicos, no sentido de que você pode provisioná-los conforme necessário, destruí-los conforme necessário, anexá-los e desconectá-los das instâncias sem reinicializar e tirar instantâneos e cloná-los sem usar o processador, a memória ou a E / S da instância. E, sem uma tabela de partições, redimensionar quando precisar de mais espaço é o bolo.
Precisa de um sistema de arquivos maior? Se você estiver usando o volume inteiro sem uma tabela de partições, é muito simples.
Faça um instantâneo de EBS do volume usando o console da AWS, com o volume ainda montado e em uso. Você não vai realmente usar esse instantâneo, mas confie em mim por um momento. Se você fez recentemente um instantâneo do volume e ainda o tem, pode pular este passo, porque o objetivo aqui é tornar o restante das etapas mais rápido.
Desmonte o volume.
Faça um segundo instantâneo. Este é o que você quer. Fizemos o anterior porque ele tornará esse instantâneo muito mais rápido. Quando o EBS tira um instantâneo, ele salva o conteúdo do disco em um repositório oculto no S3. Para cada instantâneo consecutivo do mesmo volume, somente os blocos alterados precisam ser armazenados, portanto, este instantâneo será construído, principalmente, com ponteiros armazenados para o local de todos os dados que já foram capturados, e Apenas os blocos alterados serão fisicamente salvos.
Crie um novo volume usando o último instantâneo.
Anexe o novo volume à instância no lugar do antigo e monte-o. Verifique os dados conforme necessário.
Em seguida, você pode usar resize2fs para aumentar o sistema de arquivos para preencher o tamanho disponível no novo volume, enquanto o volume estiver em uso.
Em seguida, exclua o primeiro instantâneo acima. O EBS irá "avançar" tudo o que ele contém que também é necessário pelo snapshot final, então o snapshot final ainda é válido.
Como etapa final, você pode querer aquecer o novo volume usando sudo dd if=/dev/xvdx of=/dev/null bs=1M . Quando um volume é criado a partir de um instantâneo, o conteúdo do volume é carregado "preguiçosamente" do instantâneo para o volume real, o que significa que o volume fica totalmente disponível antes de seu desempenho ser ideal. Se você pedir algo do volume que ainda não foi carregado pelo processo em segundo plano, você ainda o obterá quase imediatamente, mas não tão rápido quanto se o processo em segundo plano tivesse carregado tudo. A operação dd , acima, faz uma leitura física do volume inteiro, fazendo com que a coisa toda esteja disponível com a menor latência possível, mais rapidamente do que seria possível. Isso é documentado como algo que deve ser feito com o volume desmontado, mas se você faz isso antes ou depois do redimensionamento não é muito importante. Os vários tipos de volumes do EBS de pré-aquecimento são discutidos no link ...
Para mim, usar o volume inteiro para o sistema de arquivos, sem uma tabela de partição, parece ser o único caminho a ser seguido, pois minimiza o tempo de inatividade e a possibilidade de erro. Todos os meus volumes EBS (e efêmeros, por exemplo) são feitos desta forma, exceto alguns muito antigos.
Você pode, é claro, usar fdisk ou parted para criar e modificar a tabela de partição da maneira habitual, mas - na minha opinião - isso está adicionando desnecessariamente "partes móveis" adicionais ... que geralmente se traduz em mais oportunidades de erro.
Se você souber como trabalhar com o X-Server da sua máquina local e aceitar conexões de entrada da instância do EC2 para exibir a saída da GUI localmente, também poderá usar facilmente a ferramenta gráfica gparted em instâncias do EC2, com a interface gráfica exibida na sua tela de estação de trabalho local - sim, isso funciona, eu fiz isso - mas conseguir esse trabalho está fora do escopo desta questão.