APRENDER. PRATICAR. EVOLUIR.Começar pela identidade e pelo mapa
Num servidor de reconciliação fictício, /srv/ledger deve usar um XFS num LV linear. Antes de alterar capacidade, desenha a relação dispositivo, PV, VG, LV, filesystem e ponto de montagem. O nome /dev/sdb, isolado, não identifica de forma suficiente o disco aprovado. Compara inventário, identidade estável, tamanhos, tipos e utilização observada. Usa lsblk com colunas explícitas e relaciona a saída com lvs e findmnt. Um disco com tamanho semelhante pode pertencer a outro serviço. O exercício começa por observação: nenhum comando de criação de metadados deve ser usado para descobrir se um dispositivo contém dados.
Calcular extents e reserva
Neste modelo didático, o VG tem 3072 extents livres e cada extent mede 4 MiB. Existem 12288 MiB, ou 12 GiB, disponíveis. Crescer um LV linear simples em 16 GiB exige 4096 extents: faltam 1024. O espaço livre dentro de outro filesystem não está automaticamente disponível no VG. Acrescenta ao cálculo a reserva operacional acordada: com 24 GiB livres e pedidos de 8 e 12 GiB, restam 4 GiB. Se a reserva mínima for 6, o pedido cabe fisicamente mas não cumpre a condição local. Os números assumem alocação linear sem RAID, thin provisioning ou arredondamento adicional.
Ler o tamanho pedido antes de executar
Um LV de 40 GiB deve passar para 60 GiB. O argumento -L +20G exprime o incremento; -L 60G exprime o tamanho final. Trocar as formas muda o pedido. Se usares +60G, pedes mais sessenta, não sessenta no total. O plano deve registar tamanho inicial, final e diferença, além de confirmar extents livres. O argumento +100%FREE consome a reserva disponível e não exprime um alvo fixo de sessenta. Se uma etapa falhar, mede de novo antes de repetir um incremento relativo. Copiar novamente o mesmo comando pode produzir uma segunda alteração válida mas indesejada.
Validar volume e filesystem separadamente
O dispositivo pode crescer sem o filesystem utilizar o espaço adicional. Se lvs mostra 60 GiB e o XFS montado ainda tem cerca de 40 GiB, confirma primeiro que estás a observar a origem correta. O crescimento XFS exige uma montagem ativa e capacidade suficiente no dispositivo. xfs_growfs usa o ponto de montagem; sem -D tenta usar a capacidade máxima suportada. Com -D, o tamanho é expresso em blocos do filesystem. Para bsize=4096, um alvo didático de 60 GiB corresponde a 15728640 blocos, mas isso não equivale a uma promessa sobre espaço utilizável, geometria ou overhead de metadados.
Retomar a partir do estado parcial
--resizefs junta operações sobre camadas diferentes; um erro não é prova de rollback global. Conserva a saída, identifica a etapa que falhou e observa os tamanhos efetivos. Se o LV já cresceu, repetir +20G pode consumir mais capacidade sem corrigir o problema do filesystem. Mantém a distinção entre falha técnica e efeitos do batch: um checkpoint numa base de dados pode persistir mesmo que faltem ficheiros. Antes de retomar processamento, reconcilia resultados e usa o procedimento aplicacional suportado. A equipa de storage pode recuperar capacidade sem ter autoridade ou informação para decidir se uma transação deve ser repetida.
Definir aceitação e reversibilidade reais
Na documentação RHEL 10 consultada, XFS não suporta redução. Um pedido para devolver capacidade não se resolve por lvreduce baseado apenas na ocupação apresentada por df. Planeia migração para outro filesystem, com consistência, metadados, capacidade e recuperação verificadas. Para uma extensão, os critérios de aceitação incluem origem correta, tamanhos coerentes, acesso pela identidade do serviço e um resultado funcional controlado. Regista também a reserva restante e o responsável pela observação. O laboratório proposto deve usar uma VM descartável com recuperação disponível. Os cálculos executáveis da plataforma verificam apenas os números declarados; não substituem um ensaio RHEL com dispositivos reais.
lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS
lvs -o lv_name,lv_size,vg_name,vg_free
findmnt -M /srv/ledger -o SOURCE,TARGET,FSTYPE,OPTIONS
df -hT /srv/ledgerLV=40 GiB; VG livre=24 GiB; alvo=60 GiB. O incremento de 20 GiB deixa 4 GiB de reserva. Se o filesystem continuar em 40 GiB, identifica a etapa em falta antes de repetir qualquer incremento.
Armadilhas comuns
Repetir um incremento relativo, confundir GiB com blocos, contar espaço livre de um filesystem como extents do VG ou presumir que um erro reverteu todas as etapas.
Tópicos relacionados: Montagens persistentes · Reconciliação de batches
Seleciona a identidade certa, calcula capacidade e reserva, observa cada camada e retoma a partir do estado comprovado.
Referência: RHEL 10 logical volume management · EX200 based on Red Hat Enterprise Linux 10