← Storage: capacidade, desempenho e recuperação
07 / 12 · 60 MIN

Nomes, descritores e publicação

Diagnostica diferenças entre caminhos e objetos abertos, identifica alocação e avalia o alcance de uma substituição de ficheiro.

Preparar uma observação controlada

O laboratório cria uma pasta temporária exclusiva, usa ficheiros pequenos e remove apenas os seus próprios artefactos ao terminar. A evidência regista CPython 3.13.1 e Darwin 27.0.0 arm64. Não foi usada uma máquina Linux, uma partilha NFS ou um volume de produção. Esta distinção permite aprender com resultados executados sem afirmar equivalência entre plataformas. Antes de cada grupo, prevê qual é o nome visível, qual é o objeto aberto e onde devem aparecer os bytes seguintes. Depois compara a previsão com a saída JSON. No trabalho real, começa por identificar o filesystem e o contrato de acesso da aplicação. Um caminho com o mesmo texto pode resolver para outro alvo ou coexistir com descritores ainda ligados a um objeto anterior.

Remover o nome não muda o descritor

No primeiro grupo, active.log contém OLD e fica aberto. Removemos o nome, verificamos contagem de links zero e criamos outro active.log com NEW. Escrever pelo descritor antigo produz OLD-MORE no objeto anterior; ler pelo caminho novo devolve NEW. A observação não mede espaço livre global nem prova o momento em que um dispositivo recupera blocos. Demonstra a associação mantida pelo descritor. Num incidente de logs, apagar e recriar o caminho pode deixar o escritor no objeto errado. Identifica o processo e o procedimento suportado para reabrir o destino, conserva a evidência necessária e valida a chegada de novas entradas ao objeto esperado. Evita intervenções indiscriminadas em todos os processos.

Duas formas de referência, riscos diferentes

O segundo grupo cria linked-a e um hard link linked-b. Ambos referem o mesmo objeto. Alterar o primeiro byte por linked-b muda também a leitura por linked-a. Remover linked-a deixa linked-b utilizável com o conteúdo alterado. Este comportamento impede tratar esse segundo nome como cópia independente. O terceiro grupo cria um symlink e remove o alvo; o link continua presente, mas já não permite ler o conteúdo. Compara os dois mecanismos em vez de usar a expressão genérica temos outra ligação como garantia de proteção. Para uma migração, inventaria referências e consumidores. Uma ligação pode manter acesso partilhado ou apenas um caminho para resolver; nenhuma dessas observações substitui uma estratégia de recuperação validada.

Comprimento e alocação respondem a perguntas distintas

O quarto grupo aumenta o comprimento de um ficheiro para 1048576 bytes sem escrever esse volume de dados. No host registado, st_blocks é zero e uma leitura na zona não escrita devolve zeros. O resultado mostra um ficheiro sparse com comprimento lógico superior à alocação contabilizada. Não promete zero blocos noutra implementação, nem ausência de metadata. Ao estimar uma cópia, identifica se a ferramenta e o destino preservam essa representação ou materializam os bytes. Soma de tamanhos aparentes, alocação do filesystem e consumo de um pool físico podem divergir. Num relatório de capacidade, indica sempre a unidade, a camada e o mecanismo relevante antes de converter uma listagem de ficheiros em necessidade de espaço.

Substituição visível e durabilidade

No quinto grupo, um leitor abre VERSION-A e o caminho é substituído por um ficheiro preparado com VERSION-B no mesmo diretório. O leitor antigo continua a ler A; uma nova abertura lê B. Não existe teste de corte de energia. A documentação Linux distingue persistência do conteúdo e da entrada de diretório: sincronizar o ficheiro não cobre automaticamente essa entrada. Também é preciso tratar erros e validar o procedimento no alvo. Se dados e manifesto forem dois ficheiros substituídos separadamente, um consumidor pode observar gerações diferentes. O ensaio de um rename não demonstra uma transação conjunta. Define um protocolo de publicação e leitura que preserve coerência e inclui falhas relevantes nos testes autorizados.

Oficina: explicar o estado ao suporte

Desenha uma tabela com nome, objeto aberto, escritor, conteúdo observado e ação proposta para o caso active.log. Explica porque o novo nome não resolve sozinho a rotação. Em seguida, compara o caso de hard link com o de symlink e identifica qual sobrevive à remoção do outro nome e em que condições. Por fim, propõe critérios para publicar dados e manifesto sem aceitar gerações misturadas. A entrega da oficina é uma decisão justificada e uma lista do que ainda precisa de ensaio no ambiente relevante. Não foram realizadas sessões humanas nem testes em partilhas de rede. O resumo operacional é simples: observa identidade e referências antes de agir sobre nomes.

python3 content/labs/storage-evidence/run.py
# Open old object -> unlink name -> recreate name -> write through old handle
# Old handle: OLD-MORE; current path: NEW
# Replace published file: old reader sees A; new reader sees B
# Actual temporary-file exercises on recorded Darwin host; not a Linux VM.
NA PRÁTICA

Um batch fictício continua a escrever num log sem nome depois de a equipa o remover e criar outro ficheiro no mesmo caminho.

Armadilhas comuns

Tratar nome como identidade permanente, hard link como backup, tamanho lógico como alocação e rename como transação de vários ficheiros.

Tópicos relacionados: Administração Linux · NAS · Recuperação de desastre

Leva esta ideia contigo

Confirma o objeto que a aplicação usa e o que cada operação altera antes de remover, substituir ou declarar espaço recuperado.

Criar conta

Referência: os: operating system interfaces · DR Storage 2026-09; selected Linux and AWS storage behavior