Converter MiB para KiB

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

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.

Neste sentido a conta é uma multiplicação, e por um número inteiro: um mebibyte são 1.024 kibibytes, exatamente, e 1.024 é a definição, não uma medição que chegou perto.

Isso faz dela uma das poucas conversões que valem de cabeça, e o resultado dá para conferir: divida de volta e você tem que cair no número de partida, exato e sem resto para explicar.

Um MiB são 1.024 da unidade de baixo; um MB, 1.000. Nesta página isso é a diferença entre 1024 KiB e 976,5625 KiB — 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.

Uma quantidade surpreendente de limites do Unix é contada em kibibyte sem jeito nenhum de dizer isso no valor. Limites de pilha, de memória virtual e residente de um processo costumam ser todos em kibibyte. As colunas de limite de um arquivo de configuração de sistema também são. Um limite de banda dado como número puro em várias ferramentas de linha de comando também assume kibibyte por segundo. Cota de disco em bloco é kibibyte. Em cada caso o campo guarda um número inteiro e a unidade é implícita na página de manual, não em nada que você digite.

É por isso que esta conversão é uma operação de escrita, não de leitura. Você sabe que quer uma pilha de 8 MiB ou um teto de 20 MiB/s; o campo quer o número em kibibyte; e a única resposta a errar é uma falha de segmentação, uma transferência rodando numa fração da taxa pretendida, ou um limite tão grande que já era como se não existisse. Multiplique por 1.024, e escreva a cifra em mebibyte num comentário ao lado.

Toda cifra em mebibyte multiplicada por 1.024 cai num múltiplo de 1.024, e toda cifra em mebibyte que já era potência de dois cai numa potência de dois também. Ler um arquivo de configuração e achar um número desses diz que alguém pensou em mebibyte; achar um número redondo decimal na mesma posição diz que alguém pensou em megabyte, e o campo fica ligeiramente menor que pretendido.

A discrepância raramente importa sozinha e confiavelmente importa em conjunto. Um limite ajustado com o número decimal em vez do binário fica um pouco aquém, o que nenhum processo isolado vai notar; um buffer dimensionado errado numa frota inteira é uma diferença de throughput mensurável, e é impossível atribuir depois porque nada falhou de forma explícita. Número redondo em campo binário é o sinal mais barato de correção disponível.

Onde uma ferramenta aceita um sufixo, usar ele remove a conta e documenta a intenção no mesmo movimento. Comandos com sufixo K ou M leem corretamente um ano depois, o que o mesmo valor escrito como número inteiro não faz. O sufixo também sobrevive a alguém decidindo dobrar o valor, o que um inteiro multiplicado à mão geralmente não sobrevive.

A exceção é qualquer coisa que vai ser interpretada por algo além da própria ferramenta. Monitoramento, gestão de configuração e ferramenta de auditoria frequentemente comparam esses campos como número inteiro puro, e uma mistura de formatos numa frota inteira derrota a comparação. Onde isso se aplica, escolha a forma inteira deliberadamente e mantenha consistente, em vez de deixar cada máquina registrar o que o autor preferiu naquele dia.

O comando dd do GNU é o caso mais claro porque soletra os dois: um sufixo simples é 1.024 bytes, um sufixo explicitamente decimal é 1.000, e há um terceiro aceito como sinônimo do primeiro. Nada na sintaxe entrega qual dos dois você digitou, e um dd rodado com o errado copia o dado certo em pedaços de tamanho ligeiramente errado, o que costuma funcionar e ocasionalmente não funciona quando o destino é um dispositivo com tamanho de bloco fixo.

Fora disso, a regra prática é que qualquer coisa medindo uma taxa provavelmente é decimal e qualquer coisa medindo memória provavelmente é binária, porque engenharia de rede padronizou em potência de dez muito antes de o kibibyte ter nome. Um enlace de rede vendido numa certa taxa de bit por segundo é decimal, então um teto de banda convertido a partir de uma velocidade de enlace deveria ser calculado em decimal e só depois virar o kibibyte que a ferramenta quer.

O tamanho padrão de pilha de 8 MiB aparece como um número redondo em kibibyte porque é a unidade em que esse limite é contado, e vale converter em vez de copiar porque a cifra é por thread, não por processo. Um servidor com centenas de threads reserva esse espaço de endereço centenas de vezes, o que numa máquina de 64 bits é de graça e numa de 32 bits esgota o espaço de endereço muito antes de esgotar memória de verdade.

Diminuir o limite é uma alavanca de ajuste real e um risco real. Um valor menor é suficiente para a maioria do código de aplicação e insuficiente para um interpretador profundamente recursivo ou qualquer coisa que coloca um buffer grande na pilha. A falha é uma violação de segmento sem mensagem nenhuma sobre limite, então a cifra em mebibyte vale a pena registrar ao lado da mudança.

O PostgreSQL declara suas unidades de memória com rótulo de cara decimal e as define como binárias, então vários ajustes de memória são todos múltiplos de kibibyte sob rótulos que parecem decimais. Consultar o ajuste devolve o valor na unidade que o sistema decide ser mais organizada, e internamente é guardado em blocos de 8 KiB, então o mesmo ajuste pode ser lido de três jeitos diferentes sem nenhum deles estar errado.

O MySQL aceita contagem de byte com sufixo opcional também baseado em 1.024 e relata em byte. A consequência prática para os dois é que um valor copiado de um guia de ajuste que citava megabyte fica levemente menor que pretendido por degrau de prefixo, e consideravelmente menor quando chega em ajustes na escala de gigabyte — nunca o bastante para notar e sempre o bastante para dois servidores que deveriam bater não baterem exatamente.

Multiplicar por 1.024 mantém todo valor que começou como uma fração sensata: metade, um quarto, três quartos, um oitavo, todos viram número redondo. Valores que vieram de um cálculo decimal não sobrevivem tão bem — uma fração decimal simples em mebibyte vira um número quebrado em kibibyte — e o campo vai aceitar só um inteiro, então uma decisão precisa ser tomada em vez de adiada.

Para qual lado arredondar depende do que o campo é. Um limite ou um teto deveria arredondar para baixo, porque a intenção é "não mais que isto", e passar disso derrota o propósito. Um buffer ou uma reserva deveria arredondar para cima, porque um buffer um kibibyte aquém de um limite natural pode custar uma rodada extra de alocação em cada operação. Nenhuma das escolhas importa muito; tomá-la conscientemente é o que evita uma revisão precisar descobrir qual era a intenção.