Converter GiB para TB

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 terabyte é um trilhão de bytes, ou seja 10¹². Um disco vendido como de 1 TB tem exatamente isso: o espaço que parece faltar é uma divergência sobre unidades, e não uma falta.

O fator é 0,001074, e quase ninguém carrega isso na cabeça. Arredondado para 0,00107 ele erra 0,35 % — invisível em números pequenos, e já uma unidade inteira por volta de 1.000 GiB.

É esse o número que interessa antes de arredondar: não o erro em si, mas a partir de onde ele deixa de ser desprezível. Abaixo disso o fator curto é o sensato; acima, use o campo lá em cima, que só arredonda na hora de escrever.

Um GiB são 1.024 da unidade de baixo; um GB, 1.000. Nesta página isso é a diferença entre 0,0011 TB e 0,001 TB — 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.

O número que começa essa conversão quase sempre veio de uma máquina. Um gerenciador de volumes relatando o tamanho de um pool existente, um hipervisor resumindo datastores, um painel de monitoramento mostrando consumo — todos calculam em potências de 1.024 e imprimem GiB, ou um GB nu que significa a mesma coisa. O número que termina a conversão vai para um pedido de compra ou orçamento, e todo fornecedor, incluindo os provedores de nuvem que atendem o Brasil, cotam terabytes decimais.

Isso torna a conversão uma questão de fronteira, não um exercício de aritmética, e é exatamente na fronteira que a unidade se perde. Um requisito viaja de um engenheiro até um formulário de compras como um número solto, é lido como decimal porque o formulário é decimal, e o pedido acaba sendo por sete por cento menos capacidade do que foi solicitado. Nada no processo está errado, exceto que a unidade parou de viajar junto com o número.

A maioria das conversões de unidade tem consequências simétricas: ficar um pouco acima ou um pouco abaixo custa aproximadamente o mesmo. Esta não. Uma compra de capacidade que fica abaixo do requisito não se corrige com configuração, ajuste fino ou chamado de suporte. Corrige-se comprando mais hardware, o que significa nova aprovação, novo prazo de entrega e nova janela de manutenção.

Então a regra é arredondar para cima até a próxima capacidade disponível e depois aplicar as margens de projeto em cima. 4.000 GiB são 4,295 TB, e precisa de um disco maior que 4 TB. 8.000 GiB são 8,59 TB. 20.000 GiB são 21,47 TB. Em cada caso, a aritmética cai um pouco além de um tamanho de catálogo, o que não é coincidência — os tamanhos de catálogo são números decimais redondos, e os requisitos são números binários redondos.

Uma tabela curta cobre a maior parte das compras. 500 GiB são 0,537 TB. 1.000 GiB são 1,074 TB. 1.024 GiB — um tebibyte — são 1,0995 TB. 2.000 GiB são 2,147. 5.000 GiB são 5,369. 10.000 GiB são 10,737. O multiplicador é 0,001074 de GiB para TB, ou de forma mais fácil de lembrar: some 7,4% e mova a vírgula três casas.

A linha do 1.024 é a que vale internalizar, porque é onde a intuição falha. Um tebibyte não é um terabyte, é 1,0995 deles, então um requisito descrito como "um terabyte" por um engenheiro olhando um monitor binário precisa de uma compra de 1,1 TB, e não existe produto assim vendido. Esse único desencontro está por trás de muitos volumes provisionados exatamente no tamanho que acaba sendo pequeno demais.

A ordem das operações decide se o número final significa alguma coisa. Comece com a capacidade útil na unidade em que o requisito foi medido — GiB — porque é o valor que alguém realmente precisa. Converta para TB. Depois aplique o layout de redundância, que é um multiplicador sobre a compra e não sobre o requisito: um espelhamento dobra o valor, paridade simples sobre oito membros acrescenta um oitavo, paridade dupla sobre oito acrescenta um quarto.

Fazer na ordem contrária produz números que não dá para conferir. Aplicar a conversão de unidade depois da aritmética de paridade mistura uma correção de 7,37% dentro de uma de 25% e torna as duas invisíveis, então quando o array entregue fica menor do que o esperado ninguém consegue dizer qual etapa errou. Duas linhas separadas com duas justificativas separadas sobrevivem a uma revisão; um número único e misturado não.

Consoles de nuvem são a versão mais aguda desse problema porque as duas unidades aparecem a poucos cliques de distância uma da outra. É comum um volume de bloco ser criado com um tamanho em gibibytes, o gráfico de uso ser desenhado em gibibytes, e a página de preços cotar uma taxa por gigabyte-mês. Cada uma é internamente consistente e a combinação não é intuitiva.

A consequência prática cai na fatura, não na capacidade: um volume criado em 1.000 GiB são 1.074 GB de armazenamento faturável, então a conta fica 7,4% acima de uma estimativa ingênua feita a partir do valor de provisionamento. É uma pequena porcentagem de um número recorrente grande — exatamente o formato de uma variação de custo que só é notada com um trimestre de atraso.

É tentador tratar os 7,4% como folga — comprar no valor convertido e chamar a diferença de margem. Não é margem, é a mesma quantidade escrita corretamente, e gastá-la deixa o projeto sem margem nenhuma. Crescimento, snapshots, reservas de sistema de arquivos e o penhasco de desempenho que a maioria dos sistemas de armazenamento atinge antes de encher são reservas separadas, e cada uma precisa do seu próprio número.

O hábito útil é escrever o plano como uma cadeia que se pode conferir depois: requisito útil em GiB, o mesmo valor em TB, o multiplicador de layout, a reserva de crescimento do ciclo de compra, o tamanho de catálogo escolhido. Cinco linhas, cada uma defensável isoladamente, com a conversão à vista para qualquer um conferir, em vez de embutida numa margem que ninguém consegue verificar.

Um array redundante só usa tanto de cada membro quanto o menor deles oferece, então um conjunto montado com discos de tamanho nominalmente igual pode perder capacidade para uns poucos gigabytes de diferença entre fabricantes. Isso é um risco real há tanto tempo quanto os discos são vendidos por números decimais redondos, e é o motivo de controladoras corporativas frequentemente arredondarem cada membro para baixo até um valor comum antes de montar o conjunto.

Isso importa para essa conversão porque significa que o valor de compra não pode ser um total solto. Um requisito de 40.000 GiB, convertido para 42,95 TB e satisfeito por onze discos de 4 TB, é uma ordem diferente de satisfeito por seis discos de 8 TB — os dois têm tempo de reconstrução diferente, exposição a falhas diferente, e total útil diferente depois da paridade. Converta primeiro, depois escolha o tamanho do membro, depois confira se a aritmética ainda cobre o requisito com o layout aplicado.