Converter TiB para MiB

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 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 multiplicação, e por um número inteiro: um tebibyte são 1.048.576 mebibytes, 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 TiB são 1.024 da unidade de baixo; um TB, 1.000. Nesta página isso é a diferença entre 1048576 MiB e 953674,3164 MiB — 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.

Dividir um tebibyte por um mebibyte dá 1.048.576, e em quase todo contexto em que alguém faz essa conversão esse quociente é o ponto. Quantas partes o upload vai ter. Quantos blocos o índice de backup vai guardar. A aritmética em bytes é exata e sem graça; a contagem de peças esbarra num limite, e o limite geralmente é sobre a contagem.

Isso reformula o que um tamanho de bloco é. Não é uma unidade nem um ajuste de desempenho isolado — é o divisor que decide se a operação é possível. Escolhê-lo copiando um padrão e só descobrindo o teto no fim de uma transferência de horas é o jeito mais comum disso dar errado.

O protocolo multiparte do S3 e as muitas implementações que o copiam permitem no máximo 10.000 partes por upload, um tamanho mínimo de parte de 5 MiB para toda parte exceto a última, um tamanho máximo de parte de 5 GiB, e um objeto máximo de 5 TiB. Três desses quatro são limites de tamanho e o que realmente morde é a contagem.

A consequência é um teto que é propriedade da configuração, não do serviço: tamanho de bloco vezes 10.000. A 5 MiB isso são 48,83 GiB. A 8 MiB são 78,125 GiB. A 64 MiB são 625 GiB, a 128 MiB são 1,22 TiB e a 512 MiB são 4,88 TiB, onde o teto do próprio objeto começa a ser a restrição decisiva.

O AWS CLI usa por padrão um bloco de 8 MiB com um limiar de 8 MiB, e a maioria dos SDKs escolhe algo parecido. É um padrão sensato para os arquivos que as pessoas normalmente enviam, e falha a 78,125 GiB, distante o bastante do uso comum para que uma equipe rode por anos antes de encontrar isso. Quando encontra, a falha chega depois de setenta e oito gibibytes já transferidos.

Aumentar isso é uma única linha de configuração, e o valor deveria ser escolhido contra o maior objeto que o sistema algum dia vai produzir, não o maior que produz hoje. Um bloco de 128 MiB cobre 1,22 TiB e um de 512 MiB cobre essencialmente toda a faixa permitida, ao custo de uma unidade de nova tentativa maior e mais memória retida por parte simultânea.

O piso é o total dividido por 10.000. Um tebibyte precisa de partes de pelo menos 104,86 MiB; um objeto de 5 TiB precisa de pelo menos 524,29 MiB. Arredondar para a próxima potência de dois dá 128 MiB e 1.024 MiB respectivamente, e vale usar o número redondo porque mantém a contagem de partes limpa em vez de algo recalculado toda vez que o objeto cresce.

O teto é definido pela memória e pelo custo de nova tentativa em vez do protocolo. Um cliente segurando oito partes simultâneas de 128 MiB tem um gibibyte em trânsito, tranquilo num servidor e não tranquilo num contêiner com limite de 512Mi.

Uma parte que falha é retransmitida inteira. Numa conexão que cai ocasionalmente, partes pequenas significam que uma falha custa pouco e partes grandes significam que custa muito — uma interrupção a 90% de uma parte de 1 GiB descarta 900 MiB de trabalho. Numa conexão muito confiável o cálculo se inverte, porque cada parte carrega uma requisição, uma assinatura e uma viagem de ida e volta.

O meio-termo prático é dimensionar as partes para que uma leve entre um e cinco segundos na conexão que você realmente tem. A 100 Mbit/s isso são aproximadamente 16 a 64 MiB; num link gigabit são 128 a 512 MiB.

Vazão em armazenamento de objetos vem de partes em trânsito, não do tamanho da parte. Um único fluxo é limitado pelo tempo de ida e volta e não vai saturar um link rápido não importa quão grandes sejam as peças. Oito ou dezesseis partes simultâneas tipicamente vão, e a melhora entre um fluxo e oito é bem maior que qualquer coisa alcançável mudando o tamanho do bloco.

Isso significa que os dois ajustes deveriam ser escolhidos na ordem certa: escolha o tamanho de parte a partir do total e do limite de partes, depois escolha a concorrência a partir do link e do orçamento de memória. Fazer o contrário — aumentar o tamanho do bloco esperando velocidade — produz uma transferência que não fica mais rápida, usa mais memória, e perde mais trabalho a cada nova tentativa.

Ferramentas de backup com deduplicação fracionam com o objetivo oposto. Em vez de um tamanho fixo em mebibyte, usam fronteiras definidas por conteúdo com uma média-alvo — frequentemente cerca de um mebibyte — para que inserir bytes no início de um arquivo mude só as fronteiras perto da mudança em vez de todas as fronteiras depois dela.

A contagem de peças continua governando o custo. Um tebibyte numa média de um mebibyte fica na ordem de um milhão de blocos, cada um precisando de uma entrada de índice com um hash, então o índice do repositório chega a dezenas ou centenas de mebibytes e precisa ficar na memória durante um backup. Dobrar o tamanho médio do bloco reduz o índice pela metade e reduz a taxa de deduplicação.