Convertir MiB a TiB

Un mebibyte son 1.024 kibibytes, es decir 1.048.576 bytes. Las herramientas de Linux y las cifras de memoria se refieren casi siempre a esto, aunque escriban «MB».

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.

En este sentido la cuenta es una división, y por un número entero: 1.048.576 de estas caben en un tebibyte sin que sobre nada. Lo incómodo es solo que los resultados salen en fracciones —un tercio de tebibyte, un doceavo— en lugar de las cifras redondas que da el sentido contrario.

Aun así no se pierde nada al redondear, porque la división es exacta. Si el resultado no se queda quieto en decimales —0,0833… y parecidos—, eso es la fracción asomando, no un error colándose.

Un MiB son 1.024 de la unidad de debajo; un MB, 1.000. En esta página eso es la diferencia entre 0 TiB y 0 TiB —un 4,9 %—, 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 4,9 %. Un disco vendido en MB 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 0 TiB donde la caja ponía 0 TiB. 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.

Entre las dos unidades hay 2²⁰, de modo que cualquier cifra que tenga sentido expresar en tebibytes y que se recogiera en mebibytes se armó a partir de algo del orden del millón de elementos: objetos de un depósito, volúmenes diarios acumulados durante años, archivos de una fonoteca, fragmentos de un catálogo de copias. Ese es el marco útil para la conversión: la división en sí es exacta y trivial, y todo lo que puede estar mal en el resultado ya estaba mal antes de dividir.

También fija la precisión que merece la pena arrastrar. La última cifra significativa de un total en tebibytes con un decimal vale unos cien mil mebibytes, así que un total citado como 14,6 TiB ya ha tirado un centenar de gibibytes de detalle y no tiene sentido discutir los últimos objetos. Cuando el total es un presupuesto y no una medición, dos cifras significativas suelen ser todo lo que el dato de entrada merece.

La forma más común de este cálculo es un caudal por un periodo. Una tubería de registros que ingiere 4.200 MiB al día guarda 1.533.000 MiB al cabo de un año, es decir 1,46 TiB; la misma tubería con noventa días de retención guarda 378.000 MiB, o sea 0,36 TiB, y la distancia entre esas dos cifras suele ser el contenido entero de una discusión sobre política de retención.

Antes de citar el número conviene hacer dos ajustes. El crecimiento se compone, así que un volumen que sube un diez por ciento por trimestre acaba un 46 % más alto al cabo del año y el producto simple describe el promedio y no el pico. Y la retención se aplica borrando, y el borrado va con retraso: una política de noventa días sobre un sistema que barre una vez por semana llega a guardar noventa y siete. Los dos efectos empujan en la misma dirección, y un plan dimensionado con el producto plano queda algo corto.

Los inventarios de almacenamiento de objetos suelen dar un recuento y un total, de los que sale una media, y la media es el peor estadístico que tiene esa distribución. Los depósitos reales tienen cola larga: una mediana de decenas de kibibytes con una media en los megabytes significa que un puñado de objetos grandes carga con casi todos los bytes, y cualquier estimación que multiplique el recuento por la media acertará aproximadamente en capacidad y no servirá para nada más.

Lo que falla es justo lo que cuesta tiempo en vez de espacio. La duración de una restauración, el coste de listar, el cargo por petición y el paralelismo de una transferencia escalan con el número de objetos y no con el total de bytes, y un tebibyte repartido en cuatrocientos objetos no se parece en nada a un tebibyte repartido en cuarenta millones. Si la cifra en tebibytes va a entrar en un plan de recuperación, lleva al lado el recuento y no la media.

Un objeto almacenado es más que su contenido. Los almacenes de objetos guardan metadatos por objeto; los sistemas de archivos guardan un inodo y una entrada de directorio por archivo; varias clases de almacenamiento facturan un tamaño mínimo por objeto sea cual sea el real, lo que convierte un depósito de objetos pequeños en una factura de varias veces la suma de sus longitudes. Ceph escribe objetos RADOS de 4 MiB por omisión, y una carga menor no llena uno.

Nada de eso aparece en una columna de mebibytes exportada de un inventario, así que la conversión da un total exacto de bytes de contenido y una subestimación de lo que costará guardarlos. La corrección es un multiplicador aplicado al recuento de objetos y no al total de bytes, y por eso el recuento tiene que sobrevivir a la agregación. Diez millones de objetos con un mínimo facturable de 128 KiB son 1,19 TiB de facturación antes de mirar siquiera el contenido.

La aritmética entera aguanta aquí más de lo que sugiere el instinto. Los números de coma flotante de doble precisión representan de forma exacta todos los enteros hasta 2⁵³, que en mebibytes son más de ocho mil millones de tebibytes, así que una hoja de cálculo, un script de awk o una reducción en JavaScript sobre un inventario no van a perder un byte mientras lo que sumen sean números enteros. El ancho del acumulador no es el riesgo.

El riesgo es convertir pronto. Pasar cada fila a una cifra fraccionaria de tebibytes y sumar esas sí redondea en cada paso, porque un valor como 0,0000038 TiB no tiene representación binaria exacta y un millón de ellos acumulan un error visible. Suma en la unidad más pequeña que ofrezcan los datos —bytes si los hay, mebibytes si no— y convierte exactamente una vez, al final, cuando vaya a leerlo una persona.

Una suma en mebibytes es tamaño lógico, y casi ningún sistema guarda el tamaño lógico. Una réplica triple lo triplica. El código de borrado añade una fracción que fija el esquema: una disposición 6+3 cuesta 1,5 veces el contenido y una 8+2, 1,25. Un RAID 6 sobre diez unidades cuesta 1,25. Las instantáneas añaden lo que haya divergido desde que se tomaron, que no tiene tope y casi nunca se modela.

La compresión tira en sentido contrario y se aplica antes de la replicación y no después, así que el orden importa: total lógico, después ratio de compresión, después réplica o código, y al final cualquier mínimo por objeto. Hacerlo en otro orden da otro resultado, y un plan de capacidad que no diga en qué orden lo hizo no lo puede comprobar nadie más. Escribe primero la cifra bruta en tebibytes y deriva el resto de ella en secuencia.

Por debajo de una décima de tebibyte la unidad deja de ayudar. 104.858 MiB son 0,1 TiB, y quien lee entiende mucho mejor «102 GiB» que un número con un cero delante y tres decimales detrás. El umbral que funciona es si la cifra tiene dos dígitos antes de la coma; si no los tiene, baja un escalón y usa gibibytes.

Por arriba vale lo mismo otra vez a partir de 1.024 tebibytes, y hay un segundo motivo para tener cuidado: las cifras del orden del pebibyte se citan casi siempre junto a contratos y facturas, que se escriben en decimal. Un plan que llega a cuatro dígitos de tebibytes es un plan que se va a leer al lado de un número en terabytes, y el diez por ciento que los separa merece decirse antes de que lo descubra alguien.