Converter GiB para KiB

Um gibibyte são 1.073.741.824 bytes, cerca de 7 % a mais que um gigabyte. O Windows mede em gibibytes mas rotula «GB», e é nisso que consiste todo o mistério do espaço que some.

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 gibibyte são 1.048.576 kibibytes, exatamente, e 1.048.576 é 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 GiB são 1.024 da unidade de baixo; um GB, 1.000. Nesta página isso é a diferença entre 1048576 KiB e 976562,5 KiB — 7,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.

Uma tabela de partição guarda início e comprimento em setores. O LVM guarda extensões físicas. O mdadm guarda um tamanho de chunk em kibibytes. O mkfs recebe uma contagem de blocos. Nenhuma dessas é a unidade em que alguém decide o tamanho de um volume, então todo layout de disco envolve converter uma cifra em gibibytes para baixo pelo menos uma vez, e normalmente para duas unidades menores diferentes na mesma sessão.

Os números que valem ter à mão são 1.048.576 KiB, 2.097.152 setores de 512 bytes, e 262.144 blocos de 4 KiB por gibibyte. Os três são potências exatas de dois, o que é conveniente e também o motivo de uma resposta errada parecer plausível: um erro de fator dois ainda produz um número arrumado, e só conferir contra a capacidade total vai revelar isso.

Por muito tempo, a primeira partição num disco de PC começava no setor 63, porque a geometria que a BIOS relatava colocava sessenta e três setores numa trilha, e a primeira trilha guardava o registro de boot. Sessenta e três é ímpar, então toda fronteira derivada dele era ímpar, e quando discos passaram a ter setores físicos de 4 KiB ainda apresentando setores lógicos de 512 bytes, todo bloco de sistema de arquivos caía atravessando dois setores físicos.

Começar no setor 2048 — um mebibyte adentro — resolveu isso escolhendo um deslocamento divisível por toda granularidade em jogo: setores físicos de 4 KiB, páginas flash de 8 KiB e maiores, chunks de RAID de 512 KiB, extensões de LVM de 4 MiB. O custo é um mebibyte de disco, que em escala de gigabyte é um erro de arredondamento, e toda ferramenta de particionamento usa isso por padrão há mais de uma década. Um layout herdado que começa em outro lugar vale conferir antes de ser estendido.

O custo é um ciclo de ler-modificar-escrever, e se aplica a escritas, não a leituras. Um disco com setores físicos de 4 KiB não consegue escrever menos que um, então um bloco de sistema de arquivos de 4 KiB que atravessa dois deles força o disco a ler os dois, mesclar e escrever os dois de volta. Na memória flash, a unidade equivalente é o bloco de apagamento, e a amplificação é maior, porque o controlador precisa realocar e eventualmente apagar bem mais do que foi escrito.

Nada disso aparece num número de capacidade, num atributo SMART ou numa saída de df — o volume funciona e relata exatamente o tamanho que deveria. Aparece como taxa de escrita aleatória que é uma fração do que o hardware promete, e como amplificação de escrita que encurta a vida de um SSD. Conferir é barato: parted /dev/sda align-check optimal 1 responde diretamente, e cat /sys/block/sda/queue/optimal_io_size dá a granularidade que o disco preferiria.

O LVM aloca em extensões físicas de 4 MiB por padrão, então um volume lógico de 100 GiB são 25.600 extensões, e qualquer tamanho que não seja múltiplo de 4.096 KiB arredonda para cima até um. É por isso que lvcreate -L 10G e lvcreate -L 10GiB conseguem produzir volumes do mesmo tamanho, enquanto lvcreate -l 100%FREE produz algo que parece arbitrário — é exato em extensões e desarrumado em gibibytes.

O RAID acrescenta outra camada. O mdadm usa por padrão um chunk de 512 KiB, e uma faixa (stripe) através de n discos de dados tem n chunks de largura, então um RAID 5 de cinco discos tem uma faixa de 2 MiB. A criação do sistema de arquivos deveria ser informada disso: o mkfs.ext4 recebe stride e stripe-width em blocos de sistema de arquivos, e acertar eles permite que escritas de faixa completa evitem a leitura de paridade. Todas essas são decisões no nível de kibibyte tomadas por baixo de um tamanho de volume escolhido em gibibytes.

O hábito mais seguro é dar o sufixo e deixar a ferramenta converter. O parted aceita KiB, MiB, GiB e TiB explicitamente, e parted -a optimal vai colocar a fronteira na granularidade certa sem você precisar dizer. O sfdisk aceita tamanhos com sufixos K, M e G que são binários. O mkfs.ext4 recebe uma contagem de blocos, então um tamanho em gibibytes precisa virar 262.144 blocos por GiB, e errar isso produz um sistema de arquivos que cabe e não preenche a partição.

Onde um número puro é inevitável, escreva a cifra em gibibytes num comentário ou numa mensagem de commit ao lado. Um script de layout cheio de números como 2097152 e 209715200 está correto e completamente opaco, e a próxima pessoa a mudar ele vai converter um deles e não o outro. A aritmética é exata nas duas direções; a documentação é o que some.

O parted print, na unidade padrão dele, arredonda para três algarismos significativos, e o fdisk -l imprime uma string em tamanho humano. Os dois são para leitura. Quando o tamanho vai ser usado — para conferir que duas partições batem num espelhamento, para descobrir se um disco de substituição é grande o bastante, para dimensionar uma cópia com dd — mude a ferramenta para setores e pegue o inteiro exato. parted unit s print e blockdev --getsz dão isso.

Isso importa mais na hora de substituir um disco falho num array. Dois discos vendidos com a mesma capacidade podem diferir em alguns mebibytes, e um espelhamento não aceita um membro menor que o existente. A convenção que evita o problema é deixar uma folga deliberada — particionar para uma cifra redonda de gibibytes um pouco abaixo do tamanho real do disco — para a contagem exata de setores do próximo disco nunca precisar bater.

Uma partição de 100 GiB são 104.857.600 KiB, e um sistema de arquivos ext4 novo sobre ela vai relatar visivelmente menos. O diário ocupa uma quantidade fixa, comumente 128 MiB num volume desse tamanho. Tabelas de inode são alocadas de antemão, um inode a cada 16 KiB por padrão, a 256 bytes cada — cerca de 1,6 GiB num volume de 100 GiB. Cinco por cento é reservado para o root por padrão, que o tune2fs -m consegue reduzir num volume de dado onde nada precisa da reserva.

Isso chega perto de sete gibibytes contabilizados antes de um byte sequer ser escrito, e nada disso é perda — são as estruturas que fazem o sistema de arquivos funcionar, mais uma reserva que existe para um disco cheio não virar um disco irrecuperável. Onde o volume vai guardar poucos arquivos grandes, mkfs.ext4 -T largefile corta a contagem de inodes drasticamente e devolve a maior parte da tabela de inode.