Convertir TiB a MiB

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 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».

En este sentido la cuenta es una multiplicación, y por un número entero: un tebibyte son 1.048.576 mebibytes, exactamente, y 1.048.576 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 1048576 MiB y 953674,3164 MiB —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 953674,3164 MiB donde la caja ponía 1048576 MiB. 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.

Dividir un tebibyte entre un mebibyte da 1.048.576, y ese cociente es casi siempre la razón por la que alguien hace esta cuenta. Cuántas partes tendrá una subida, cuántos fragmentos ocupará una copia de seguridad, cuántos archivos saldrán de un reparto. La aritmética de bytes es exacta y aburrida; el número de piezas choca con un límite, y ese límite casi siempre recae sobre la cantidad, no sobre el total.

Eso cambia lo que es un tamaño de fragmento: no es una unidad ni un ajuste de rendimiento aislado, sino el divisor que decide si la operación es posible. Copiar el valor por defecto de una herramienta y descubrir el techo solo al final de una transferencia de varias horas es el error más habitual, y la cuenta que lo habría evitado tarda unos segundos.

El protocolo de subida multiparte de S3 y las implementaciones compatibles comparten los mismos cuatro números: 10.000 partes como máximo, 5 MiB como mínimo por parte salvo la última, 5 GiB como máximo por parte y 5 TiB como objeto máximo. Tres de esos cuatro son límites de tamaño; el que de verdad muerde es el de cantidad, porque el cliente fija un tamaño de fragmento una sola vez y sigue generando partes hasta agotarlas.

El resultado es un techo que depende de la configuración, no del servicio: tamaño de fragmento por 10.000. Con 5 MiB son 48,83 GiB. Con 8 MiB son 78,125 GiB. Con 64 MiB, 625 GiB; con 128 MiB, 1,22 TiB; con 512 MiB, 4,88 TiB, donde ya empieza a pesar más el límite del objeto que el de las partes.

rclone y buena parte de los clientes S3 heredan un tamaño de fragmento por defecto cercano a 8 MiB, pensado para los archivos que se suben habitualmente, y ese valor falla en 78,125 GiB. Es un umbral suficientemente alto como para que alguien trabaje años sin tropezar con él, y cuando lo hace, el fallo llega después de haber transferido ya setenta y ocho gibibytes, que es el peor momento posible para perderlo.

Subirlo es cuestión de una línea de configuración, por ejemplo --s3-chunk-size 128M en rclone o el equivalente en el cliente que se esté usando, y conviene elegir el valor pensando en el objeto más grande que el sistema llegará a producir, no en el que produce hoy. Un fragmento de 128 MiB cubre hasta 1,22 TiB; uno de 512 MiB cubre casi todo el rango permitido, al precio de un reintento más caro y más memoria retenida por cada parte en curso.

El suelo es el total dividido entre 10.000. Un tebibyte necesita partes de al menos 104,86 MiB; un objeto de 5 TiB necesita al menos 524,29 MiB. Redondear a la siguiente potencia de dos deja 128 MiB y 1.024 MiB, y merece la pena quedarse con la cifra redonda porque mantiene el número de partes en un valor limpio, 8.192 o 5.120, en vez de algo que hay que recalcular cada vez que el objeto crece.

El techo lo marca la memoria y el coste de reintentar, no el protocolo. Un cliente con ocho partes de 128 MiB en curso tiene un gibibyte en tránsito, asumible en un servidor y no en un contenedor con 512 MiB de límite. Donde quien sube el archivo corre bajo un tope de memoria, el producto de tamaño de parte por concurrencia es la cifra a comprobar, no cada factor por separado.

Las herramientas de backup que deduplican, restic y Borg entre las más usadas fuera del entorno corporativo, no cortan en fragmentos de tamaño fijo sino en límites definidos por el contenido, con un promedio objetivo que suele rondar el mebibyte. Insertar bytes al principio de un archivo desplaza solo los límites cercanos al cambio, no todos los que vienen después. Un corte de tamaño fijo obligaría a reescribir todo el flujo de fragmentos ante una sola inserción, y por eso no se usa donde la deduplicación importa.

El número de piezas sigue mandando en el coste. Un tebibyte con un promedio de un mebibyte produce del orden de un millón de fragmentos, cada uno con su entrada de índice y su hash, así que el índice del repositorio ocupa decenas o cientos de mebibytes y hay que mantenerlo en memoria durante la copia. Duplicar el tamaño medio del fragmento reduce el índice a la mitad y baja la tasa de deduplicación, el ajuste que conviene revisar cuando un repositorio se ha vuelto lento, más que cuando se ha quedado sin espacio.

El motivo por el que S3 subdivide en partes en primer lugar es que una subida de un tebibyte como bloque único no sobrevive a un corte de red a mitad de camino: hay que empezar de cero. Con partes independientes, cada una confirmada por separado, una conexión que se cae solo obliga a repetir la parte que estaba en curso; el resto queda subido y el cliente puede listar qué partes ya llegaron antes de reanudar.

Esa es la razón práctica para preferir más partes pequeñas frente a menos partes grandes cuando la conexión es la que falla, no el ancho de banda: cuantas más piezas tenga el tebibyte, menos trabajo se pierde en cada corte. El límite de 10.000 y el mínimo de 5 MiB fijan entre qué dos extremos se puede mover esa decisión, y el punto medio razonable rara vez coincide con el valor que trae el cliente por defecto.