APRENDER. PRATICAR. EVOLUIR.A janela faz parte da medição
O sétimo grupo usa amostras sintéticas, sem ler contadores do host. Em oito segundos, leituras concluídas passam de 100 para 228 e setores de 1000 para 5096. A diferença corresponde a 128 leituras e 4096 setores. Usando os setores de 512 bytes definidos para estes contadores Linux, obtemos 16 leituras por segundo, 262144 bytes por segundo e 16384 bytes por leitura concluída. São valores da camada observada; não identificam automaticamente chamadas da aplicação, porque outras camadas podem combinar ou dividir operações. Guarda identidade do recurso, época, duração e unidades com a amostra. Sem esse contexto, um número correto pode responder à pergunta errada.
Uma quebra de continuidade não é tráfego negativo
O mesmo grupo fornece depois um contador menor, como poderia acontecer após substituição ou reset do recurso. A função devolve ausência de taxa para essa janela. Usar valor absoluto inventaria atividade; publicar um número negativo sugeriria um fenómeno que o contador não representa. O procedimento de diagnóstico deve conservar a descontinuidade e obter uma nova referência comparável. Considera também alterações de identidade que mantenham valores crescentes: monotonia numérica por si só não prova continuidade do mesmo dispositivo. O modelo rejeita apenas as condições explicitamente implementadas e não descobre automaticamente hotplug, wraps ou agregações incorretas. Num painel operacional, apresenta a lacuna e o seu motivo antes de comparar períodos.
A mistura determina a procura de bytes
No oitavo grupo, metade das operações tem quatro KiB e metade 256 KiB. A mistura é por número de operações, pelo que o tamanho médio é 130 KiB. Um limite fictício de 125 MiB/s suporta, sem overhead, 125×1024/130, ou cerca de 984,6 operações por segundo dessa mistura. O teto de 4000 IOPS não elimina a limitação de throughput. Não foi executado benchmark nem consultado um volume cloud; os números são premissas do exercício. Antes de comprar capacidade, confirma a mistura na mesma camada e janela, os limites agregados e a latência observada. Depois mede o efeito de uma alteração autorizada com uma carga representativa.
Reservar margem física
O nono grupo começa com 120 GiB físicos livres e prevê oitenta de procura nova, trinta de crescimento adicional de snapshots e vinte de reserva obrigatória no cenário. Restam dez, logo o plano fica dez abaixo da reserva. O cálculo assume consumo adicional já estimado; não soma tamanhos lógicos de snapshots como se todos fossem cópias completas. A implementação determina partilha de blocos, metadata e crescimento ao longo do tempo. Revê o plano quando a retenção ou o padrão de escrita mudar. Um filesystem que ainda mostra espaço não garante margem no pool subjacente. O laboratório só calcula o orçamento fictício e não altera pools, volumes ou políticas de retenção.
Copiar corretamente também copia erros
O sexto grupo cria um ledger JSON com total declarado 100 e entradas quarenta e 59. Copiamos o ficheiro e os hashes coincidem, mas a validação da soma falha com total real 99. A cópia foi fiel ao conteúdo errado. Não se deve corrigir arbitrariamente o total para obter verde; é preciso investigar a regra e os dados com o responsável adequado. A operação copyfile também não demonstra preservação de todas as permissões, ACLs ou metadata necessárias à aplicação. Define verificações de conteúdo, acesso, dependências e resultado funcional. O exercício não é um restauro de base de dados nem um teste de recuperação de uma aplicação financeira real.
Oficina: aceitar uma recuperação
Prepara um plano fictício com dez minutos para acesso, vinte para cópia e quinze para validação, todos sequenciais. Com RTO de quarenta, faltam cinco minutos antes de acrescentar margem. Explica ao sponsor porque o fim da transferência aos trinta minutos ainda não demonstra o resultado requerido. Junta o caso do ledger: descreve o que passou, o que falhou, quem decide e que alternativa precisa de ser investigada. O facilitador deve procurar unidades corretas, distinção entre factos e premissas e condições explícitas de aceitação. O guião está disponível, mas não foi executado por um grupo humano. Relaciona o exercício com disaster recovery, observabilidade e passagem para operação normal.
python3 content/labs/storage-evidence/run.py
# Reads: 100 -> 228 over 8s => 16/s
# Sectors: 1000 -> 5096; 512 bytes/sector => 256 KiB/s
# Mean completed read: 16 KiB
# Mix by operation count: 50% 4 KiB + 50% 256 KiB = 130 KiB/op
# 125 MiB/s / 130 KiB = 12800/13 IOPS (theoretical ceiling)Uma equipa fictícia propõe mais IOPS para acelerar um batch, enquanto o limite de bytes e a validação da recuperação continuam fora do plano.
Armadilhas comuns
Dividir um contador acumulado sem delta, ocultar resets, tratar limites como garantias, ignorar snapshots e usar hash como validação de negócio.
Tópicos relacionados: Administração Linux · NAS · Recuperação de desastre
Uma decisão credível junta medições com unidades coerentes, premissas explícitas e prova do resultado de que o negócio necessita.
Referência: Block layer statistics · DR Storage 2026-09; selected Linux and AWS storage behavior