Converter GiB para TiB

Um gibibyte são 1.073.741.824 bytes, cerca de 7 % a mais que um gigabyte. O Windows mede em gibibytes mas rotula «GB», e é nisso que consiste todo o mistério do espaço que some.

Um tebibyte são 1.024 gibibytes. A distância em relação ao terabyte cresce a cada degrau: 2,4 % no quilo, 4,9 % no mega, 7,4 % no giga e 10 % no tera.

Neste sentido a conta é uma divisão, e por um número inteiro: 1.024 dessas cabem em um tebibyte sem sobrar nada. O incômodo é só que os resultados saem em frações — um terço, um doze avos — em vez dos números redondos que o sentido contrário dá.

Mesmo assim não se perde nada, porque a divisão é exata. Se o seu resultado não quer parar quieto em decimais — 0,0833… e parentes —, isso é a fração aparecendo, não um erro se instalando.

Um GiB são 1.024 da unidade de baixo; um GB, 1.000. Nesta página isso é a diferença entre 0,001 TiB e 0,0009 TiB — 7,4 % — e a distância cresce a cada degrau: por isso é arredondamento desprezível numa foto e um pedaço visível de um HD.

O mistério do espaço que some é inteiro isso. Um disco vendido como um terabyte tem exatamente o que diz em unidades decimais; o Windows reconta em unidades binárias e mantém o nome decimal, então o número encolhe sem que nada tenha se perdido. O macOS conta em unidades decimais desde o 10.6, e é por isso que o mesmo disco pode aparecer com dois tamanhos em dois computadores.

Disco é vendido em terabyte decimal e pool é contado em unidade binária, então a primeira coisa que acontece com uma compra é um corte de dez por cento que não é corte nenhum. Um disco de 4 TB carrega exatamente quatro trilhões de bytes como anunciado, o que dá cerca de 3.725,29 GiB, ou 3,638 TiB. Oito deles somam cerca de 29,10 TiB, e a nota diz 32 TB. Nada se perdeu entre essas duas cifras; são os mesmos bytes contados em bases diferentes.

A segunda conversão é a que de fato remove capacidade real, e vem depois: paridade ou espelhamento, a reserva que o sistema de arquivo guarda, e o teto de enchimento que qualquer pessoa sensata planeja respeitar. Manter as duas separadas é o que torna um plano de capacidade conferível. Declare a cifra bruta em tebibyte primeiro, depois cada dedução com um motivo, em vez de apresentar um número quarenta por cento abaixo da nota sem mostrar a conta.

Essa costuma ser a fonte mais comum de uma cifra em gibibyte que não bate. Um comando de nível de pool relata o tamanho bruto do conjunto de discos, paridade incluída, porque é o que essa camada gerencia. Um comando de nível de sistema de arquivo relata o que o conjunto de dados consegue armazenar de fato, paridade excluída. Num pool de oito discos com dupla paridade, o primeiro vai mostrar mais ou menos um terço a mais que o segundo, e os dois estão corretos.

A regra que segue disso é tirar a cifra de capacidade da camada que combina com a pergunta. Planejar quanto dado vai caber é uma pergunta da camada de arquivo. Calcular se um disco de reposição é grande o bastante é uma pergunta da camada de pool. Converter a errada para tebibyte e colocar num plano produz um conjunto que esgota um terço mais cedo do que a planilha dizia.

A conta principal é simples. Um espelhamento entrega metade. Uma configuração com paridade simples entrega n menos um disco de dado. Uma com dupla paridade entrega n menos dois. Oito discos de 3.725,29 GiB numa configuração de dupla paridade entregam seis discos de dado, cerca de 21,83 TiB, e os mesmos oito como quatro pares espelhados entregam cerca de 14,55 TiB, com comportamento de reconstrução bem melhor.

O preenchimento tira mais uma fatia que a conta principal não vê. O sistema de arquivo aloca em unidades derivadas do tamanho de setor, então registros que não dividem igualmente entre os discos de dado deixam lacunas, e o efeito é pior com registro pequeno num conjunto largo. Para um servidor de arquivo geral a perda é pequena; para um pool guardando um banco de dados com registro pequeno, pode chegar a um quinto da capacidade nominal, o que vale modelar antes de montar o pool, não descobrir depois.

Um sistema de arquivo do tipo copiar-ao-escrever não consegue liberar um arquivo sobrescrevendo um bit no lugar; precisa escrever metadado novo, o que exige espaço livre. Um pool que chegasse a zero de espaço livre de verdade, portanto, ficaria incapaz de apagar qualquer coisa, um estado sem saída. O sistema evita isso guardando uma fração — um trigésimo segundo do pool por padrão — que escrita comum não consegue tocar.

Num pool de 32 TiB isso é cerca de 1 TiB reservado, e não aparece como espaço livre no número que o usuário vê. É uma proporção fixa, não uma quantidade fixa, então cresce com o pool, e é uma das deduções que deveria aparecer explicitamente num plano de capacidade.

O desempenho de alocação num pool do tipo copiar-ao-escrever degrada conforme o espaço livre se fragmenta, e degrada de forma abrupta, não gradual. O alocador precisa buscar mais para achar espaço contíguo, escrita fica espalhada, e leitura sofre junto porque o dado caiu espalhado. A orientação comum é planejar para oitenta por cento num pool de uso geral e menos para um com carga pesada de escrita aleatória.

Isso transforma 32 TiB de capacidade usável em cerca de 25,6 TiB de capacidade de planejamento, e tratar a diferença como margem para comer num trimestre movimentado é como um pool acaba lento e difícil de recuperar. Converter o total em gibibyte para tebibyte e aplicar o teto na mesma etapa dá um número só para planejar contra.

Um pool não cresce em qualquer quantidade arbitrária. Adicionar capacidade significa adicionar outro bloco da mesma forma, ou substituir todo disco de um bloco existente por um maior e deixar expandir quando o último terminar. Alguns sistemas recentes conseguem adicionar um disco isolado a um bloco existente, mas o dado antigo mantém a proporção de paridade antiga até ser reescrito, então a cifra usável se move menos do que a conta simples sugere.

A consequência para o planejamento é que o incremento de crescimento é grande e conhecido de antemão. Um bloco de oito discos de 4 TB com dupla paridade acrescenta cerca de 21,83 TiB de uma vez, então um plano que vai estourar a capacidade em dezoito meses tem uma decisão de compra com um tamanho discreto, não uma taxa. Calcular o incremento em tebibyte cedo deixa claro se o próximo passo é um bloco ou dois.

Um instantâneo não custa nada quando tirado e cresce conforme o dado ativo diverge dele. Um conjunto de dados guardando alguns tebibyte com um mês de instantâneos diários e um padrão de reescrita pesado pode consumir várias vezes isso, e nada desse crescimento aparece no tamanho do dado atual. Um relatório detalhado do sistema de arquivo divide isso em usado, usado por instantâneo, usado pelo conjunto de dados e usado por reserva, e é ali que um déficit inexplicado costuma estar.

A consequência de planejamento é que a cifra usável em tebibyte precisa ser reduzida por uma margem de retenção de instantâneo, e essa margem depende da taxa de reescrita, não do tamanho do dado. Um arquivo de mídia escrito uma vez precisa de quase nada; um repositório de máquina virtual onde cada convidado reescreve o sistema de arquivo todo dia precisa de um múltiplo grande. Onde a taxa é desconhecida, medir por duas semanas é bem mais barato que descobrir na hora em que o pool enche.