Converter TiB para GB

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.

Um gigabyte é um bilhão de bytes, no sentido decimal usado pelos fabricantes de disco, pelos planos de dados e pelos tamanhos de vídeo.

Um TiB são 1.024 da unidade de baixo; um TB, 1.000. Nesta página isso é a diferença entre 1099,5116 GB e 1000 GB — 10 % — 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.

Arrays relatam tebibytes. Um pool ZFS, a página de resumo de um NAS, um sistema de arquivos Linux consultado com tamanhos legíveis por humano — todos contam em potências de 1.024, e a cifra que acaba anotada e levada para um documento de planejamento é um TiB. Listas de preço, páginas de cota e diálogos de provisionamento são majoritariamente em GB decimal, porque é essa a unidade em que capacidade é vendida desde muito antes de alguém vendê-la por mês.

Entre os dois há uma multiplicação por 1.099,511627776. Um pool de 12 TiB são 13.194 GB, não 12.000, e a diferença de 1.194 GB é quase 10 por cento do orçamento. Nada na conversão redonda parece errado numa página — 12 TiB e 12.000 GB leem como a mesma quantidade para quase todo mundo —, motivo pelo qual esse erro sobrevive à revisão e aparece primeiro numa fatura.

A conversão é só metade do problema, porque o campo que você está preenchendo pode ele mesmo significar gibibytes. Volumes de armazenamento em bloco frequentemente são provisionados em GiB enquanto armazenamento de objetos frequentemente é cobrado por GB decimal, e os dois podem estar no mesmo console sob rótulos parecidos. Ler a documentação do serviço é o primeiro passo certo e nem sempre responde à pergunta.

O que sempre responde é uma medição. Provisione ou armazene uma quantidade cuja contagem de bytes você conhece, leia o que o serviço relata, e divida: a razão vai ser exatamente 1.000.000.000 ou exatamente 1.073.741.824, e não há nada no meio para ser. Uma observação por serviço resolve isso permanentemente e vale registrar em algum lugar que a próxima pessoa vai achar.

Uma capacidade usável em TiB fica a várias subtrações de distância dos discos que precisam ser comprados. Converta a exigência usável para bytes; some a redundância, que para paridade simples num conjunto de discos custa a capacidade de um deles e para espelhamento custa metade de tudo; some a folga que o sistema de arquivos precisa para continuar performando bem; depois converta para os terabytes decimais em que os discos são rotulados.

Fazer essas etapas em unidades misturadas é como um pool acaba um disco a menos. Cada subtração precisa se aplicar a uma cifra num sistema conhecido, e a tentação é tirar 9 por cento aqui e um disco ali até a resposta parecer plausível. Em bytes, cada etapa é conferível e a conversão final acontece exatamente uma vez, no ponto em que o número vira um pedido de compra.

Armazenamento cobrado por gigabyte por mês multiplica seja lá qual quantidade receber, então um erro na quantidade é um erro em toda fatura enquanto os dados existirem. Cotar uma migração de 12 TiB como 12.000 GB em vez de 13.194 subestima 1.194 GB por mês, permanentemente, e a falta não fica visível em número nenhum na fatura — só fica visível como um total que não bate com a estimativa.

O mesmo vale para qualquer outra coisa cobrada por volume: transferência, snapshots, réplicas numa segunda região. Cada uma é um multiplicador sobre uma quantidade base, e cada uma herda o erro de unidade que a base carrega. Acertar a base uma vez vale mais do que conferir cada linha depois, que é o argumento geral para cotar em bytes e deixar cada sistema apresentar a cifra nas próprias unidades.

O resumo de um pool costuma mostrar vários números que parecem capacidade e não são a mesma coisa: capacidade bruta pelos discos, capacidade usável depois da redundância, espaço alocado e espaço livre, às vezes com economias de compressão e deduplicação embutidas num deles. Comparar o par errado produz uma discrepância atribuída a unidades quando é um problema de definição.

A ordem certa de leitura é bruta, depois usável, depois alocada. Bruta deveria ficar perto da soma das etiquetas dos discos convertidas de TB decimal para TiB — cerca de 91 por cento do número nas caixas. Usável deveria ser bruta menos a redundância. Alocada deveria ser menor que usável pelo que estiver livre. Se qualquer uma dessas três relações não bater, a explicação está na configuração, não na aritmética.

Camadas de armazenamento que comprimem ou deduplicam relatam um tamanho lógico e um físico, e a razão entre os dois é propriedade dos dados, não do sistema. Um pool guardando dados altamente compressíveis pode armazenar mais bytes lógicos do que sua capacidade física, o que torna qualquer previsão baseada em cifras lógicas pouco confiável nas duas direções.

Para um orçamento, isso significa declarar qual cifra está sendo cotada. Uma migração cotada em tamanho lógico e cobrada em físico, ou o contrário, produz uma diferença bem maior que os 9,95 por cento de que esta página trata. A conversão de unidade é exata e pode ser resolvida uma vez; a razão de compressão é uma estimativa que precisa ser medida numa amostra representativa e declarada como suposição.

O hábito que remove essa classe inteira de disputa é carregar a contagem de bytes em todo documento que mais de uma organização vai ler. Um orçamento que diz 13.194 GB e dá 13.194.139.533.312 bytes ao lado pode ser conferido por qualquer um, convertido para qualquer convenção, e comparado com qualquer lista de preço sem uma conversa sobre de quem é o gigabyte pretendido.

Custa uma coluna e muda sobre o que é a discordância. Com bytes na página, uma divergência é uma pergunta sobre o que está sendo contado — snapshots, réplicas, overhead —, que é uma discussão que os dois lados conseguem ter de forma produtiva. Sem eles, a primeira hora vai toda em estabelecer se alguém está falando da mesma quantidade, e essa hora se repete em cada etapa do projeto.