Convertir TiB a KiB

Un tebibyte son 1.024 gibibytes. La distancia respecto al terabyte crece en cada escalón: 2,4 % en kilo, 4,9 % en mega, 7,4 % en giga y 10 % en tera.

Un kibibyte son exactamente 1.024 bytes. El nombre se introdujo en 1998 para que «kilobyte» pudiera volver a significar 1.000, aunque la costumbre nunca llegó a imponerse del todo.

En este sentido la cuenta es una multiplicación, y por un número entero: un tebibyte son 1.073.741.824 kibibytes, exactamente, y 1.073.741.824 es la definición, no una medición que se quedó cerca.

Eso convierte esta en una de las pocas conversiones que merece la pena hacer de cabeza, y hace que el resultado se pueda comprobar: divide de vuelta y tienes que caer en el número de partida, exacto y sin resto que justificar.

Un TiB son 1.024 de la unidad de debajo; un TB, 1.000. En esta página eso es la diferencia entre 1073741824 KiB y 976562500 KiB —un 10 %—, y la distancia crece en cada escalón: por eso es un redondeo despreciable en una foto y un trozo visible de un disco duro.

En eso consiste entero el misterio del espacio que falta, y en esta página vale un 10 %. Un disco vendido en TB tiene exactamente lo que dice la etiqueta; lo que pasa después es que Windows divide entre 1.024 en vez de entre 1.000, conserva el nombre decimal y muestra 976562500 KiB donde la caja ponía 1073741824 KiB. macOS cuenta estas cifras en unidades decimales desde 10.6, y por eso el mismo disco puede parecer de dos tamaños en dos ordenadores: no falta nada ni redondea nadie, son los mismos bytes con dos nombres.

Un tebibyte son 1.073.741.824 kibibytes, que es 2³⁰ y por tanto la misma cifra que tiene un gibibyte contado en bytes. Diez dígitos en una casilla que normalmente contiene tres o cuatro, sin separadores de millar y sin ninguna validación que sepa qué orden de magnitud era razonable: si sobra un cero, la cuota queda en diez tebibytes y el sistema la acepta encantado.

La comprobación previa es contar los grupos de tres empezando por la derecha: tienen que salir tres grupos completos detrás del uno. Y hay una referencia que conviene reconocer, porque aparece justo al lado: dos tebibytes son 2.147.483.648 bloques, una unidad por encima del mayor entero de 32 bits con signo. Cualquier herramienta de esta cadena que todavía use ese tipo se rompe exactamente ahí.

La contabilidad de cuotas de la familia ext y de xfs trabaja en bloques de 1 KiB con independencia del tamaño de bloque real del sistema de archivos. Es un detalle que sorprende la primera vez: el disco asigna en bloques de 4 KiB y la cuota se lleva en unidades de 1 KiB, de modo que las dos cifras que uno mira no están en la misma escala aunque las dos digan «bloques».

La consecuencia es que el consumo declarado de un usuario es un múltiplo de cuatro, porque cada bloque real asignado suma cuatro unidades de cuota. Sirve como comprobación rápida de que se está leyendo la columna correcta: si un consumo no es divisible entre cuatro, la cifra que se está mirando no es la de bloques asignados sino otra cosa, probablemente una suma de tamaños de fichero.

Una cuota son en realidad dos números. El límite blando se puede superar temporalmente y arranca un plazo de gracia; el duro no se puede superar en absoluto y la escritura falla en el momento. Cuando el plazo expira sin haber vuelto por debajo del blando, el blando pasa a comportarse como duro, que es la parte que nadie recuerda hasta que ocurre.

Poner los dos al mismo valor convierte el mecanismo en un único umbral y desperdicia lo único que lo hace útil: el aviso. Una separación razonable —el blando en el requisito acordado y el duro un diez o un quince por ciento por encima— da margen para que alguien reaccione antes de que un proceso se caiga a mitad de una escritura. El plazo por omisión suele estar en varios días, y conviene mirarlo en lugar de suponerlo, porque decide cuánto tiempo real hay para actuar.

Las cuotas limitan también el número de inodos, es decir de ficheros, y ese límite es independiente del de bloques. Un usuario puede quedarse sin poder crear ficheros con la cuota de espacio a media ocupación, o al revés, y el mensaje de error es el mismo en los dos casos, lo que convierte el diagnóstico en una pequeña adivinanza si no se mira el informe completo.

Dimensionar el límite de inodos requiere una estimación del número de ficheros y no del volumen de datos, así que no se deduce de la cifra de esta página. La regla práctica que suele funcionar es partir del recuento actual, multiplicarlo por el crecimiento previsto y añadir un margen generoso: un límite de inodos alto no consume nada mientras no se use, mientras que uno bajo detiene el trabajo sin avisar.

Algunas herramientas de administración de cuotas aceptan sufijos y otras no, y las que los aceptan no coinciden todas en qué significan. Donde el sufijo esté documentado y probado, es más legible que el entero y menos propenso a errores de teclado. Donde no lo esté, el entero es la única opción que no depende de una interpretación.

La costumbre que resuelve el conflicto es escribir las dos cosas: el entero en el campo y la operación que lo produjo en el comentario, el ticket o el fichero de configuración que gestiona ese sistema. «1.073.741.824 bloques de 1 KiB = 1 TiB» es una línea que permite a cualquiera comprobar la cuota sin rehacer la conversión, y evita que la próxima revisión la cambie por un número redondo que parece más limpio y significa otra cosa.

Una reserva o un proyecto con espacio garantizado apartan bloques que aún no contienen nada, y esos bloques dejan de estar disponibles para el resto en el momento de crearse. Si la suma de las reservas se acerca a la capacidad del volumen, el sistema puede rechazar escrituras de un usuario que va sobrado de cuota simplemente porque el espacio libre pertenece ya a otro.

Por eso las cuotas y las reservas se planifican juntas y contra la misma cifra de capacidad. Sumar todas las cuotas de un volumen y comprobar el total contra su tamaño real es un ejercicio de cinco minutos que suele revelar un sobrecompromiso importante; sobrecomprometer puede ser una decisión perfectamente sensata, pero solo si alguien la ha tomado a propósito.

Hay situaciones en las que la cuota de bloques es la restricción equivocada. Un usuario con millones de ficheros minúsculos topa antes con los inodos; un directorio compartido por varios procesos se limita mejor por proyecto que por usuario; y un sistema donde el problema real es el ritmo de escritura no se arregla con ningún límite de capacidad, porque el disco se llena igual, solo que más despacio.

Merece la pena preguntarse qué se está intentando evitar antes de convertir nada. Si es que un volumen se llene, el techo agregado del volumen es más directo que la suma de cuotas individuales. Si es repartir un recurso escaso entre equipos, la cuota por proyecto es la herramienta. La conversión de tebibytes a bloques es solo el último paso, y solo cuando la respuesta a esa pregunta es «un límite por usuario».