Converter TiB para GiB

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.

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.

Neste sentido a conta é uma multiplicação, e por um número inteiro: um tebibyte são 1.024 gibibytes, 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 TiB são 1.024 da unidade de baixo; um TB, 1.000. Nesta página isso é a diferença entre 1024 GiB e 931,3226 GiB — 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.

Quase toda interface que solicita armazenamento pede um valor em gibibytes. Volumes de bloco em nuvem são provisionados em GiB inteiros. Uma reivindicação de volume persistente do Kubernetes se escreve storage: 100Gi. Disco de máquina virtual, volume lógico LVM e alvo iSCSI são especificados nessa escala. O pool por trás deles — um array, um SAN, um pool ZFS — é descrito em tebibytes, porque é a unidade em que uma compra acontece.

Então a conversão é na verdade uma divisão em contagem. Um pool de 10 TiB são 10.240 GiB, que são 102 volumes de 100 GiB, ou 20 de 512, ou 5 de 2.048. Calcular essa contagem antes de criar o primeiro volume é o que torna a vida útil do pool previsível.

Um volume com provisionamento fino relata seu tamanho cheio à máquina convidada e consome só os blocos escritos. É por isso que cem volumes de 100 GiB — 10.000 GiB de promessas — podem sentar num pool de 2 TiB consumindo 800 GiB, e é uma eficiência genuína: a maioria dos volumes está majoritariamente vazia.

A exposição é que as promessas são reais e o pool não. Quando o uso agregado se aproxima do tamanho do pool, escritas começam a falhar em volumes cujo próprio indicador de espaço livre diz que há sobra, e os sistemas de arquivos convidados não têm como interpretar isso — o resultado costuma ser corrupção em vez de um erro limpo. Pools finos precisam de monitoramento no uso do pool, não no de qualquer volume individual.

Três deduções saem do pool antes de o valor em gibibytes ser dividido: espaço de snapshot, que depende da taxa de reescrita mais do que do tamanho dos dados; um teto de preenchimento, porque a maioria dos pools degrada bem antes de encher; e espaço livre suficiente para completar uma reconstrução ou restauração — a operação mais provável de ser necessária exatamente quando o pool está mais cheio.

Num pool de 10 TiB, reservando vinte por cento para o teto e mais um tebibyte para snapshot e manobra, sobram cerca de 7.168 GiB para alocar — 71 volumes de 100 GiB em vez de 102. Essa diferença precisa ser decidida antecipadamente, porque recuperar espaço de volumes já entregues significa encolhê-los, e encolher costuma não funcionar.

Armazenamento em bloco de nuvem é provisionado em gibibytes inteiros e cobrado por gibibyte provisionado ao mês, independente do uso. Um pedido de 100 GiB é cobrado como 100, escrito ou não. Um pedido feito como "100 GB" contra uma API cujo campo é GiB entrega 7,4% mais capacidade e 7,4% mais custo do que o valor decimal sugeria — quando uma cotação e uma fatura divergem por essa fração, geralmente é essa a causa.

O mesmo arredondamento torna volumes pequenos desproporcionalmente caros em conjunto. Quinhentos volumes de 8 GiB são 4.000 GiB provisionados, 3,9 TiB, e se a utilização média for de um quarto, três tebibytes da fatura são espaço vazio.

Estender um volume e depois estender o sistema de arquivos nele é uma operação online na maioria das pilhas modernas, e leva segundos. O caminho contrário é outra classe de problema: o sistema de arquivos precisa realocar tudo que está no fim do dispositivo antes de ele poder ser truncado, e alguns sistemas simplesmente não fazem isso online. Na prática, o tamanho de um volume é uma decisão de mão única.

Essa assimetria deveria moldar a alocação inicial. Começar volumes pequenos e crescê-los sob demanda custa alguns minutos de trabalho por crescimento e mantém o espaço livre do pool disponível para quem mais precisa; começar no tamanho que alguém imaginou que eventualmente seria necessário trava o pool em alocações que nunca serão recuperadas.

Escolher tamanhos que são potências de dois, ou pelo menos frações limpas de um tebibyte, torna a capacidade restante fácil de raciocinar. 10.240 GiB divide exatamente em volumes de 128, 256, 512, 1.024 ou 2.048 GiB e não deixa nada estranho no fim. Um tamanho padrão de 750 GiB deixa 490 GiB encalhados depois de treze volumes — não o bastante para um décimo quarto e demais para ignorar.

O mesmo vale para a granularidade subjacente. Extents de LVM, tamanho de chunk de pool fino e faixas de RAID têm granularidades que um tamanho de volume ou encaixa ou não, e um tamanho que é um número inteiro de gibibytes é um número inteiro de cada uma delas.