Converter KiB para GB

Um kibibyte são exatamente 1.024 bytes. O nome foi introduzido em 1998 para que «kilobyte» pudesse voltar a significar 1.000, embora o costume nunca tenha pegado de vez.

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.

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

É 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 KiB são 1.024 da unidade de baixo; um kB, 1.000. Nesta página isso é a diferença entre 0 GB e 0 GB — 2,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 lado de medição de um sistema web conta em unidades binárias porque as ferramentas que o produzem contam assim. Um tamanho médio de objeto vem de uma listagem de arquivos, um relatório de build ou um resumo de bucket de armazenamento, e todos esses dividem por 1.024. O lado comercial conta em gigabytes decimais, porque é assim que transferência é vendida desde muito antes de alguém precisar distinguir os dois.

Um objeto sozinho não sente a diferença, e um mês de tráfego sente. Um milhão de requisições com média de 250 KiB são 256.000.000.000 bytes, que são 256 GB. Usar mil em vez de 1.024 dá 250 GB, uma subestimação de seis gigabytes que escala exatamente com o tráfego: dobre as requisições e a diferença dobra também.

A ordem confiável é manter tudo em bytes pelo maior tempo possível. Pegue o tamanho por objeto em kibibytes, multiplique por 1.024 para chegar a bytes, multiplique pela contagem, e só então divida por um bilhão. Todo passo antes do último é aritmética inteira e exata, e a única divisão no final é o único lugar em que uma decisão de arredondamento precisa ser tomada.

Fazer ao contrário — converter cada objeto para gigabytes e somar os resultados — introduz um erro de arredondamento por item, e o número de itens é exatamente a quantidade que torna o total grande. Uma planilha montada assim pode desviar vários por cento por motivos invisíveis em qualquer linha individual, o que torna a discrepância extremamente difícil de encontrar depois.

Logs de acesso registram bytes, não kibibytes, que é a única boa notícia neste cálculo. O campo bytes-enviados é uma contagem bruta por requisição, então somar a coluna e dividir por um bilhão dá gigabytes decimais sem questão de unidade nenhuma. Onde o número chega já resumido em KiB — um painel, um relatório, uma mensagem de colega —, a conversão precisa ser aplicada, e vale perguntar o que o resumo arredondou.

A outra coisa que um log conta e uma média não conta é o formato da distribuição. Um tamanho médio de objeto de 250 KiB pode ser dez mil respostas pequenas e um punhado bem grandes, e uma previsão construída sobre a média vai estar certa no total e errada em toda consequência operacional — comportamento de cache, contagem de conexões, o efeito de um limite de tamanho. O total é a parte fácil.

A carga útil não é a transferência. Cabeçalhos de resposta acrescentam algumas centenas de bytes a cada requisição e são enviados esteja o corpo em cache ou não, a negociação de protocolo custa bytes em cada conexão nova, redirecionamentos transferem duas vezes, e requisições que falharam e foram tentadas de novo são contadas a cada tentativa. Numa frota de objetos pequenos, esse overhead pode ser uma fração séria do total, e nada disso aparece no tamanho de objeto que uma listagem de armazenamento relata.

Vale dizer isso junto da correção de unidade porque os dois puxam na mesma direção e são fáceis de confundir. Se um provedor relata mais uso do que o cálculo previu, a lacuna de unidades explica 2,4 por cento disso e nada mais. Qualquer coisa além disso é tráfego que o modelo não contabilizou, e procurar isso na aritmética em vez do padrão de requisição desperdiça a tarde.

Pegue o tamanho médio de objeto em kibibytes, multiplique por 1.024 para bytes, multiplique pela contagem esperada de requisições, e divida por um bilhão. Dez milhões de requisições a 100 KiB são 1.024.000.000.000 bytes, que são 1.024 GB, ou 1,024 TB. Essa última cifra já é um marco útil de sanidade: dez milhões de objetos de cem kibibytes são quase exatamente um terabyte decimal.

Depois aplique a incerteza com honestidade. Uma previsão precisa a quatro algarismos significativos nas unidades e vaga por um fator de dois na contagem de requisições não ficou mais precisa por causa da conversão. Declare o total como uma faixa guiada pela estimativa de tráfego, e use o fator exato para que pelo menos a aritmética não acrescente erro próprio.

Reconciliação funciona melhor em bytes dos dois lados. Converta os gigabytes faturados pelo provedor de volta a bytes multiplicando por um bilhão, some as contagens de bytes dos seus próprios logs, e compare os dois inteiros. Qualquer diferença então tem uma causa que vale nomear em vez de se perder numa comparação entre duas cifras arredondadas com unidades não declaradas.

Uma discrepância de cerca de 2,4 por cento aponta para a lacuna kibibyte-versus-kilobyte em algum lugar da cadeia, geralmente num resumo produzido por uma ferramenta binária e lido como decimal. Uma discrepância de 7,4 por cento aponta para o mesmo erro cometido um prefixo acima. Reconhecer o tamanho da lacuna costuma ser mais rápido do que rastrear onde ela aconteceu.

Dois medidores diferentes rodam sobre os mesmos objetos. Armazenamento é cobrado por capacidade mantida ao longo do tempo, geralmente como gigabyte-mês proporcional à hora, então um objeto que existe o mês inteiro custa seu tamanho completo e um apagado no dia quinze custa metade. Transferência é cobrada por gigabyte movido, então o mesmo objeto não custa nada até alguém pedi-lo, e então custa seu tamanho em cada requisição que não é servida por um cache.

Os dois medidores contam gigabytes decimais, o que pelo menos significa que uma conversão cobre os dois. O que muda é por quanto a cifra em kibibytes precisa ser multiplicada: contagem de objetos para armazenamento, contagem de requisições para transferência. Uma biblioteca de um milhão de objetos de 250 KiB são 256 GB de armazenamento todo mês independente do tráfego, e de nada a muitos terabytes de saída dependendo da frequência com que é lida.

Cotas de caixa de correio, franquias de armazenamento por usuário e limites de resposta de API são frequentemente definidos em unidades binárias pelo software que os impõe e comunicados aos usuários em termos decimais, ou o contrário. Uma franquia de 15 GB imposta como 15 GiB dá a cada usuário 1,11 GB a mais do que a documentação prometeu, em toda a base de usuários, e ninguém reclama — motivo pelo qual passa despercebido por anos.

A versão que gera reclamação é o oposto. Uma franquia anunciada como 15 GB e imposta como 15.000.000.000 bytes vai parecer curta para qualquer usuário cujo cliente relate uso em gibibytes, porque seus 14 GiB de e-mail são 15,03 GB e já ultrapassaram. A correção não é mais capacidade; é declarar a unidade no mesmo lugar em que o número é declarado.