Converter TiB para KiB

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 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 tebibyte são 1.073.741.824 kibibytes, exatamente, e 1.073.741.824 é 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 1073741824 KiB e 976562500 KiB — 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.

Trinta bits separam as duas unidades, então um tebibyte vira 1.073.741.824 kibibytes, e qualquer cota realista vira um número que ninguém lê numa olhada. Dois tebibytes são 2147483648, cinco são 5368709120, dez são 10737418240. Esses são os valores que vão no campo, e o campo aceita qualquer inteiro que você der — inclusive um com um dígito a mais, que é o erro que de fato acontece.

O hábito que pega isso é contar dígitos em vez de ler o número. Um mebibyte são quatro dígitos de kibibyte, um gibibyte sete, um tebibyte dez, um pebibyte treze. Toda unidade acrescenta três, mais ou menos, então uma cota pensada como poucos tebibytes deveria ter dez ou onze dígitos, e qualquer outra coisa está errada por uma ordem de grandeza antes mesmo de olhar o valor em si.

Limite de bloco no setquota, edquota e repquota são contagens de unidades de 1.024 bytes, seja qual for o tamanho de bloco do sistema de arquivos por baixo. Esse desacoplamento é deliberado: uma cota definida num volume ext4 com blocos de 4 KiB e uma definida num sistema de arquivos com blocos de 64 KiB significam a mesma quantidade de espaço, e mover um diretório pessoal entre eles não muda a franquia de ninguém em silêncio.

Isso significa que os números reportados não batem com a unidade de contabilidade própria do sistema de arquivos, então um usuário ocupando 1.000 blocos de 4 KiB aparece como 4.000 blocos de cota. O XFS mantém a própria implementação de cota com a mesma unidade e um conjunto de ferramentas diferente — xfs_quota -c 'limit bhard=2t user=alice' aceita um sufixo e faz a aritmética sozinho, a rota melhor sempre que disponível.

O limite flexível é um aviso com dentes. Um usuário acima dele continua trabalhando enquanto um período de carência corre — sete dias por padrão — e quando a carência expira o limite flexível passa a se comportar como um rígido. O limite rígido é imediato: a escrita retorna EDQUOT e o aplicativo geralmente reporta isso como um erro de disco cheio, o que manda o usuário conferir espaço livre e encontrar bastante.

A diferença entre os dois é onde mora a decisão de projeto. Um limite flexível em 1,8 TiB e um rígido em 2 TiB dão 214.748.364 kibibytes de folga e uma semana para usar, o bastante para alguém notar um aviso e liberar espaço. Definir os dois em 2 TiB não dá aviso nenhum, e o primeiro sinal que alguém tem é um trabalho falhado. Onde os dois números são iguais numa tabela de cota, geralmente é porque quem configurou converteu um número e copiou duas vezes.

Toda cota tem um segundo par de limites contando arquivo em vez de kilobyte, e são independentes. Um usuário bem dentro de uma cota de bloco de 2 TiB ainda pode ser recusado numa escrita porque chegou no limite de inode, e o erro é a mesma mensagem de cota excedida sem indicar qual teto foi atingido. quota -s mostra os dois, e é a primeira coisa a conferir quando um usuário insiste que tem espaço.

O limite de inode existe porque inodes são um recurso fixo alocado quando o sistema de arquivos foi criado e não podem ser acrescentados depois. Uma conta única criando dezenas de milhões de arquivos minúsculos pode esgotar eles usando uma fração desprezível da cota de bloco, e nesse ponto ninguém no volume consegue criar um arquivo. Definir um limite de inode, portanto, protege o sistema de arquivos, não o usuário, e não precisa ser convertido de nada.

Algumas ferramentas dessa área aceitam um sufixo e algumas não, e saber qual vale mais que saber a conversão. xfs_quota aceita k, m, g e t e trata como binário. Versões recentes do setquota aceitam o mesmo na linha de comando. edquota coloca você num editor sobre uma tabela de inteiros nus, e qualquer valor escrito ali é kibibyte. O ZFS ignora a questão inteiramente — zfs set quota=2T é uma propriedade de conjunto de dados com o próprio analisador.

Onde o inteiro nu é inevitável, registre o número em tebibyte ao lado. Uma tabela de cota contendo 2147483648 e 2147483648 está correta e é irrevisável; a mesma tabela com um comentário dizendo 2 TiB flexível, 2 TiB rígido convida alguém a notar que o flexível deveria ter sido menor. A aritmética é exata e instantânea de qualquer jeito, então o único em jogo é se o próximo leitor consegue saber o que foi pretendido.

Uma cota é um teto e uma reserva é um piso, e a segunda é mais difícil de dimensionar. Reserva do ZFS, cota de projeto do XFS usada como garantia, e volume com provisionamento fino com um mínimo garantido, todos separam bloco que não vai ser dado a mais ninguém. Uma reserva de 2 TiB remove 2.147.483.648 kibibytes do número disponível do pool no momento em que é definida, antes de um único byte ter sido escrito nela.

É isso que faz um pool superreservado se reportar cheio enquanto parece quase vazio. A soma das reservas entre conjuntos de dados pode chegar perto do tamanho do pool com quase nenhum dado presente, e toda ferramenta que reporta espaço livre está dizendo a verdade do próprio ponto de vista. Calcular as reservas em kibibyte, somar, e comparar isso contra o total do pool na mesma unidade é a checagem que pega isso — feito em tebibyte, o arredondamento esconde várias centenas de gibibyte de compromisso.

Uma cota de bloco controla quanto um usuário guarda e nada sobre quanto escreve. Alguém criando e apagando arquivos temporários grandes repetidamente fica dentro de uma cota de 2 TiB indefinidamente enquanto gera amplificação de escrita enorme, desgastando flash e enchendo snapshot de churn. Se a preocupação é vazão ou vida útil do dispositivo em vez de capacidade, o campo de cota não é a alavanca, e nenhuma conversão vai fazer isso ser.

Snapshot complica o teto na direção contrária. Num sistema de arquivos copy-on-write, dado apagado ainda referenciado por um snapshot ainda é cobrado de algum lugar, e dependendo de como a cota é delimitada ainda pode ser cobrado do usuário que apagou. Um usuário que removeu um tebibyte de arquivos e não viu mudança no próprio uso geralmente está vendo isso, e a correção é uma política de retenção, não um número maior no campo de bloco.