Converter GB para TiB

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 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.

O fator é 0,000909, e quase ninguém carrega isso na cabeça. Arredondado para 0,00091 ele erra 0,06 % — invisível em números pequenos, e já uma unidade inteira por volta de 10.000 GB.

É 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 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.

Armazenamento é especificado nas unidades de quem escreveu o documento. Ficha técnica de disco, pedido de volume, guia de dimensionamento de banco de dados e tabela de cota estão quase todos em gigabytes decimais, porque foi assim que os componentes foram vendidos. O pool onde esses volumes acabam é relatado por software, e software conta em potências de 1.024, então o total volta em tebibytes.

Os dois não somam do jeito óbvio. Um plano de quarenta volumes de 250 GB são 10.000 GB, que soa como dez de algo e são 9,09 TiB. Quem reservou um pool de 10 TiB tem uma margem confortável que não sabia que tinha; quem reservou 9 TiB está faltando exatamente a quantia que a conversão esconde.

A divergência entre as escalas decimal e binária se acumula a cada prefixo: 2,4% no kilo, 4,86 no mega, 7,37 no giga, 9,95 no tera. Cruzar de GB para TiB usa a razão do passo tera, então a correção é a maior que alguém encontra na prática. Um décimo de um plano de capacidade não é diferença de arredondamento; é um disco, uma prateleira ou um mês de crescimento.

É também o passo em que as duas convenções param de parecer parecidas o bastante para substituir uma pela outra. Abaixo de um gigabyte, as pessoas escapam tratando as unidades como intercambiáveis porque o erro se esconde dentro da margem de segurança. No passo tera o erro é maior que a maioria das margens de segurança.

Cinco cifras cobrem a maior parte deste trabalho. 1.000 GB são 0,909 TiB. 2.000 GB são 1,819. 5.000 GB são 4,547. 10.000 GB são 9,095. 50.000 GB são 45,47. No sentido inverso, um TiB absorve 1.099,5 GB, então um pool relatado como 20 TiB aceita cerca de 21.990 GB de volumes citados em decimal.

O atalho que sobrevive a ser lembrado errado é multiplicar gigabytes por 0,0009095, ou dividir por 1.100 e aceitar um décimo de por cento de erro. Dividir por 1.024 é o erro a evitar: essa razão leva gibibytes a tebibytes, não gigabytes, e usá-la aqui reporta 0,977 TiB para 1.000 GB — um excesso de 7,4%.

A falha raramente é uma conversão errada. É uma coluna que contém os dois tipos de número. Uma planilha de dimensionamento pega capacidade de disco de uma cotação de fornecedor em TB, consumo atual de uma exportação de monitoramento em TiB, estimativa por banco de dados de um DBA em GB, e uma retenção de backup de um documento de política que não especifica.

O conserto prático é converter na entrada em vez de no final, e nomear a coluna pela unidade em vez de pelo conteúdo. Uma coluna chamada "bytes" não aceita silenciosamente uma cifra em tebibyte; uma coluna chamada "tamanho" aceita, e mais cedo ou mais tarde vai aceitar.

Num pool com provisionamento espesso, um erro de unidade se anuncia imediatamente: as alocações não cabem e algo se recusa a ser criado. Provisionamento fino remove essa checagem por design, permitindo que a soma dos tamanhos de volume exceda a capacidade física.

O que aparece depois é um pool cruzando sua marca d'água antes do que o modelo previu, aproximadamente do tamanho da conversão que foi pulada. O sintoma é uma previsão sempre revisada, não um erro, motivo pelo qual vale reconciliar o modelo contra o pool em bytes uma vez no início.

A conversão de unidade é aritmética, não é perda. As subtrações que vêm depois são reais. Paridade ou replicação tira sua parte primeiro — um pool espelhado corta pela metade, um conjunto de dupla paridade de doze dá dez membros de espaço utilizável. Estruturas de sistema de arquivos e reservas tiram mais alguns por cento.

Manter essas separadas da etapa GB-para-TiB é o que torna um modelo de capacidade auditável. Quando o pool enche antes do previsto, a primeira pergunta é qual das quatro subtrações foi subestimada, e essa pergunta só tem resposta se cada uma foi registrada como linha própria.

Um plano de backup multiplica mais unidades misturadas que qualquer outro exercício de capacidade. O dado protegido é citado em GB pelos times de aplicação. A política de retenção é uma contagem de pontos diários, semanais e mensais. A taxa de mudança é uma porcentagem. A taxa de deduplicação e compressão é um fator dado por um fornecedor. O repositório que guarda o resultado reporta em TiB.

A ordem que sobrevive à revisão é reduzir tudo a bytes no ponto de entrada, aplicar a aritmética de retenção e taxa de mudança ali, e converter uma vez no final. Vale também registrar a taxa de deduplicação como suposição em vez de medição até o repositório rodar um ciclo completo de retenção.