Converter B para MiB

Um byte são oito bits, o que nem sempre foi claro: os primeiros computadores usaram seis, sete ou nove. O oito se impôs porque nele cabe um caractere e porque o número se parte em metades limpas.

Um mebibyte são 1.024 kibibytes, ou seja 1.048.576 bytes. As ferramentas do Linux e os números de memória quase sempre se referem a isto, mesmo escrevendo «MB».

Neste sentido a conta é uma divisão, e por um número inteiro: 1.048.576 dessas cabem em um mebibyte 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 MiB são 1.024 da unidade de baixo; um MB, 1.000. Nesta página isso é a diferença entre 1048576 B e 1000000 B — 4,9 % — 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.

A contagem de bytes é o número confiável nessa conta. Ela sai de uma chamada do sistema de arquivos ou de um cabeçalho content-length, não tem ambiguidade de unidade e é o que o programa vai comparar no final. O valor em MiB é uma conveniência humana em cima disso, e todo problema nessa direção vem de tratar a conveniência como fonte de verdade e deixar que o número exato seja reconstruído a partir dela.

Faça a conversão na ordem que mantém a contagem de bytes como autoridade: divida por 1.048.576, decida para que lado arredondar, e depois multiplique de volta para confirmar que o limite escrito ainda admite o arquivo medido. Esse último passo leva segundos e evita a classe inteira de erros que esta página existe para prevenir, porque um limite não está correto quando parece certo — está correto quando o arquivo passa por ele.

Um arquivo de 10.486.000 bytes tem 10,0002 MiB. Escrito num limite de upload como "10m", ele agora é maior que o limite e será recusado, e a mensagem de erro vai dizer que o arquivo é grande demais para um limite que o operador acreditava ser exatamente do tamanho do arquivo. Arredondar para baixo é o hábito padrão, e para um teto máximo é sempre o errado — o teto precisa ser no mínimo do tamanho da maior coisa que deveria admitir.

O caso espelhado é uma reserva em vez de um teto. Espaço separado para um cache, um buffer de log ou um arquivo pré-alocado precisa arredondar para baixo, porque arredondar para cima promete capacidade que não existe, e a falta aparece depois, sob carga, como falha de escrita. Uma pergunta decide a direção sempre: se esse número estiver errado por um byte, eu prefiro ter um pouco a mais ou um pouco a menos?

Muita configuração aceita um sufixo, e o sufixo raramente diz a que sistema pertence. O nginx lê k como 1.024 e m como 1.048.576, então client_max_body_size 10m são 10.485.760 bytes. A JVM faz o mesmo com -Xmx e -Xms. O GNU dd separa explicitamente: bs=1M é 1.048.576 enquanto bs=1MB é 1.000.000, e os dois produzem arquivos diferentes a partir do mesmo comando.

O Kubernetes é o caso que vale a pena aprender, porque se recusa a adivinhar. Mi, Gi e Ti são as quantidades binárias e M, G e T são as decimais, ambas válidas num manifesto, e um limite de memória de 512M é 4,6% menor do que um de 512Mi. Nada avisa: o manifesto é aplicado, o pod inicia, e o limite não está onde deveria estar.

Um mebibyte é 2 elevado à vigésima potência, e é por isso que aparece como o tamanho natural de coisas que um kernel aloca. Páginas de memória são de 4 KiB, huge pages costumam ser 2 MiB, e um buffer dimensionado em potência de dois se alinha com todas elas sem deixar resto. Escolher 1.000.000 bytes para o mesmo buffer não está errado, é um número que o alocador por baixo tem que arredondar para cima de qualquer forma, então o alinhamento é comprado de volta num nível mais baixo ou pago numa página parcial.

A consequência prática é que valores em unidade binária se propagam. Se o tamanho do bloco é potência de dois, e o tamanho da parte é múltiplo do bloco, e o limite é múltiplo da parte, tudo divide de forma exata e nenhum estágio sobra resto no final. Introduzir um único valor decimal nessa cadeia faz cada estágio abaixo dele começar a produzir restos, o que é uma pequena ineficiência e uma grande fonte de confusão de contagem por um.

Enviar um objeto grande em partes é onde esses números deixam de ser cosméticos. Um tamanho de parte escolhido em unidade binária divide um arquivo num número inteiro de partes completas mais um resto, e a contagem de partes tem um teto, então o tamanho da parte precisa ser grande o bastante para que o objeto caiba dentro desse teto. Calcular isso a partir de um valor em MiB arredondado em vez da contagem de bytes é como um upload falha na parte 10.001, depois de já ter transferido a maior parte do arquivo.

A conferência é aritmética e vale fazer antes da transferência, não durante. Divida o tamanho exato do objeto em bytes pelo tamanho da parte em bytes, arredonde para cima, e confirme que o resultado está dentro do limite do provedor. Se estiver próximo, aumente o tamanho da parte em vez de torcer; a falha acontece no fim de um upload longo, e a essa altura o diagnóstico útil é um número que você poderia ter calculado antes.

Exibir 10,5 MiB não é problema. Armazenar 10,5 MiB e depois reconstruir a contagem de bytes é, porque a exibição já descartou tudo abaixo de cerca de mil bytes e não há como recuperar isso. Manifestos, listagens de checksum e registros de auditoria deveriam carregar a contagem de bytes e derivar o valor amigável no momento da exibição, nessa ordem, para que o número exato sobreviva a cada volta por um relatório.

A mesma regra vale para comparações. Dois objetos, ambos mostrados como 4,2 MiB, podem diferir em cinquenta mil bytes, e uma verificação de deduplicação ou drift escrita contra o valor exibido vai chamá-los de idênticos. Qualquer coisa que decida igualdade — sincronização, verificação de backup, validação de cache — compara contagens de bytes, e o valor em MiB aparece depois, para o benefício de quem lê o log.

O erro mais caro disponível nesta página não é a diferença de 4,9% entre MB e MiB — é o fator de oito entre bytes e bits. Armazenamento e tamanho de arquivo são contados em bytes; taxa de transferência é cotada em bits por segundo, motivo pelo qual uma conexão de 100 Mb/s entrega no máximo 12,5 MB/s, e o download de um arquivo de 500 MiB nela leva cerca de quarenta segundos em vez de cinco.

A convenção que os distingue é um B maiúsculo para bytes e um b minúsculo para bits, e é seguida o bastante para valer confiar e violada o bastante para valer conferir. Quando um número parece oito vezes maior ou menor do que deveria, essa é a primeira coisa a testar, antes de qualquer pergunta sobre qual milhar alguém quis dizer. Vale conferir em qualquer valor copiado de um diagrama de rede ou de uma ficha técnica de fornecedor, onde bit é a unidade da casa e byte é a exceção.