APRENDER. PRATICAR. EVOLUIR.Prever a mudança antes de executar
O laboratório cria uma LUN de 64 MiB suportada por um ficheiro em RAM. O objetivo é crescer para 96 MiB, conservando a identidade e um marcador anterior. Antes de correr o guião, desenha uma tabela com backing, target, cada caminho e mapa. Acrescenta filesystem e aplicação à tabela de um serviço real, mesmo que este ensaio não os implemente. O aumento pretendido é 32 MiB, não 96 MiB adicionais nem a soma dos caminhos. Identifica o recurso pelo WWID e regista bytes para evitar diferenças de apresentação entre MB e MiB. O resultado esperado é uma sequência de estados verificáveis. Um comando bem-sucedido numa camada não encerra automaticamente as restantes.
Atualizar o target dentro do âmbito ensaiado
Aumentar o ficheiro com truncate não atualizou o relatório da LUN TGT na execução registada. O ensaio conserva as duas observações para tornar essa diferença visível. Depois suspende o seu próprio I/O, coloca a LUN offline e reabre o mesmo ficheiro aumentado através da operação específica deste target. Só então o target passa a apresentar a capacidade nova. Este passo não é apresentado como expansão online de um array nem como garantia de ausência de impacto na aplicação. O laboratório não tem carga concorrente durante a transição. Numa infraestrutura real, a operação depende da plataforma e da combinação suportada. A equipa deve escolher o procedimento do destino e os critérios de continuidade, em vez de transplantar o comando TGT para qualquer produto.
Reconciliar todos os caminhos antes do mapa
O guião atualiza primeiro apenas um caminho. A amostra mostra 96 MiB nesse dispositivo, 64 MiB no outro e 64 MiB no mapa. Esta divergência é deliberada e não deve ser escondida num relatório que só apresente o maior valor. Depois do segundo rescan, ambos os caminhos mostram 96 MiB, mas o mapa permanece com 64 MiB porque o ensaio configura auto_resize never. A operação explícita de resize do mapa completa essa transição. Numa plataforma com outra política, o comportamento pode ser diferente; confirma o estado efetivo. Os nomes dos dispositivos não são constantes do procedimento. Num host com quatro caminhos, identifica e verifica os quatro. Conserva a identidade da LUN junto das capacidades para não correlacionar recursos diferentes.
Provar acesso à capacidade nova e planear recuperação
Após o mapa atingir 100663296 bytes, o guião lê novamente o marcador antigo e escreve outro aos 80 MiB. Esse offset ficava além do limite anterior de 64 MiB e permite testar concretamente a área acrescentada. O hash é guardado e a leitura é comparada byte a byte. O ensaio também repõe uma sessão autenticada e confirma o marcador novo pelo mapa. Estes resultados não medem todos os setores nem um filesystem. Se uma aplicação continuar sem espaço, segue o seu caminho até às camadas e quotas relevantes. Depois de usar a área nova, reduzir cegamente o backing para 64 MiB eliminaria essa região. A recuperação deve considerar os dados e o estado do consumidor, não presumir que cada operação tem um inverso seguro.
# Observe the recorded transitions in content/labs/san-growth/evidence.json.
# stage path A MiB path B MiB map MiB
# initial 64 64 64
# first path rescan 96 64 64
# both paths rescanned 96 96 64
# explicit map resize 96 96 96
# auto_resize never is explicit in this lab.
# Guarded replay and setup: content/labs/san-growth/README.txt
# No filesystem or application workload is created.O backing cresce para 96 MiB, mas o target, os caminhos e o mapa só mudam depois das respetivas operações do ensaio.
Armadilhas comuns
Saltar um caminho, somar capacidades de acessos, copiar nomes sdX ou reduzir o recurso depois de já escrever na região acrescentada.
Tópicos relacionados: Storage · Administração Linux · Gestão de mudanças
A expansão termina quando as camadas exigidas pelo serviço estão consistentes e o consumidor demonstra a capacidade utilizável acordada.
Referência: DM Multipath capacity, per-path rescan and map resize · DR SAN 2026-09; selected RHEL 9, ONTAP 9 and iSCSI behavior