Então,
Essa noite precisei testar o ‘resize’ de uma unidade LVM, mas logo pensei: E o filesystem dentro da unidade, será que vai corromper? Logicamente que sim!
Fiz backup de tudo e iniciei os testes:
Segue ordem que deve ser feita para que você possa comprovar o teste em seu VG, sendo que tem que ter no mínimo 100M de espaço disponível.
Primeiro cria-se o volume LVM com nome teste dentro de um VG já existente (volume_group):
lvcreate –size=100M –name=teste volume_group
Unidade criada, cria-se o sistema de arquivos ext3 dentro dela para testes:
mkfs.ext3 /dev/mapper/volume_group-teste
Sistema de arquivos criado, unidade pode ser mapeada para escrever algo dentro:
mkdir /teste && mount /dev/mapper/volume_group-teste /teste
vi /teste/texto.txt (escreva algo dentro)
Agora, depois de desmontar a unidade com umount, pode-se fazer o shrink (encolhimento, redução, como quiser) de forma correta:
Deve ser feita a checagem com o e2fsck usando parâmetro -f para marcar o sistema de arquivos como ‘checado’ mesmo se ele está OK para o sistema operacional…
e2fsck -f /dev/mapper/volume_group-teste
Depois o resize propriamente dito do sistema de arquivos ext3:
resize2fs /dev/mapper/volume_group-teste 50M
Agora é a hora do que nos interessa: resize do volume lógico
lvresize -L 50M /dev/mapper/volume_group-teste
Pode-se então conferir que o sistema operacional continua conseguindo ler a partição, através de um particionador comum modo texto:
parted /dev/mapper/volume_group-teste
Pode-se também repetir o e2fsck para verificar que realmente o sistema de arquivos está sem problemas..
Pode-se conferir que os dados estão íntegros:
mount /dev/mapper/volume_group-teste /teste && cat /teste/texto.txt
Por fim, remove-se a unidade criada para testes:
lvremove /dev/mapper/volume_group-teste
Obs.: Se a ordem acima for ‘atropelada’ e o resize da partição LVM for feito antes do resize do sistema de arquivos, o sistema de arquivos vai corromper, porém arquivo teste.tx pode continuar sendo lido pelo sistema operacional. Dai para corrigir o sistema de arquivos, teria que passar um fsck e rezar para que tudo consiga ser re-construído.
Muito importante: Por mais que tudo isso tenha sido testado em CentOS 5.2 e CentOS 5.3, e que pela Internet a fora tenha mais um monte de posts informando que esse procedimento dá certo, o risco sempre existe! Então, nunca deixe de realizar backup completo (seguido de conferência do backup) antes de realizar esse tipo de manutenção para shrink de partição LVM. Fica a dica!
Por: Hudson Murilo dos Santos
Referências: Google
man lvresize
man e2fsck
man resize2fs
Então, segue uma contribuição… Caso tenhamos uma unidade física maior que a partição atual, a exemplo um LUN que foi feito o increase ou até mesmo uma unidade LVM, podemos proceder. Assumimos para o exemplo abaixo a situação de: Unidade /dev/xvdb fisicamente com 170Gb, uma partição número 1 primária com 40Gb, e um filesystem ext3 respectivamente com 40Gb. Para aumentarmos o filesystem e a partição para 170Gb afim de usar todo o disco podemos proceder:
– umount /dev/xvdb1
– fdisk /dev/xvdb
– Atalhos do fdisk:
d – deleta a partição 1 (única no disco)
n – NOva partição
p – Define como primária
1 – Define a partição como número 1
– Valor default para o bloco inicial
– Tamanho total disponível em disco, ou informar +[VALOR]M
w – Escreve as alterações na tabela de alocação do disco
– resize2fs -f /dev/xvdb1
– mount /dev/xvdb1 /ponto_montagem
Lembrando sempre que um backup é bem vindo, e que para processos de redução como no artigo, basta obedecer a ordem de alteração onde primeiro se reduz o filesystem, depois a partição, e a alocação física.
Abraços…!
Perfeito Frank, entendido. Obrigado pela contribuição amigo! Muito bem colocada.