Convertir TiB a TB

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 terabyte es un billón de bytes en la cuenta corta, es decir 10¹². Un disco vendido como de 1 TB tiene exactamente eso: el espacio que parece faltar es un desacuerdo sobre unidades, no una carencia.

Un TiB son 1.024 de la unidad de debajo; un TB, 1.000. En esta página eso es la diferencia entre 1,0995 TB y 1 TB —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 1 TB donde la caja ponía 1,0995 TB. 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.

Todo proyecto de almacenamiento cruza esta línea dos veces. Los discos se eligen de una lista de precios en terabytes decimales, el pool resultante lo reporta un software que cuenta en tebibytes, y el plan de capacidad que alguien escribió en una hoja de cálculo suele quedar en la unidad en la que esa persona pensaba en ese momento. El 9,95 % de diferencia no es un redondeo a esta escala: en una compra de dieciséis terabytes son 1,45 TB, más margen del que la mayoría de planes reserva.

La conversión en sí es una sola multiplicación: tebibytes por el factor que la propia calculadora de esta página muestra como exacto, 1,09951162778, da terabytes. Lo que justifica esta página es que la cifra rara vez llega sola. Viene acompañada de un esquema de paridad, una recomendación de llenado y un sistema de archivos, cada uno de los cuales quita una porción más, y separar el cambio de unidad de las pérdidas reales es lo que convierte una cifra alarmante en un plan.

Se parte de la capacidad bruta: cuatro discos de 4 TB son 16 TB, o 16.000.000.000.000 bytes. Se divide entre 1.099.511.627.776 y el array muestra 14,55 TiB, la cifra que aparecerá en el informe del pool antes de contar la redundancia. No se ha perdido nada todavía: son los mismos dieciséis billones de bytes expresados en la unidad que prefiere el software.

Con paridad simple se pierde la capacidad de un disco, quedando 12 TB útiles, es decir 10,91 TiB. Con paridad doble quedan 8 TB, o 7,28 TiB. Un espejo de dos pares de discos llega a los mismos 8 TB por otro camino. La cifra que finalmente ve el usuario está, por tanto, a dos restas de la caja: primero un cambio de unidad de en torno al diez por ciento, después el coste de la redundancia, que según el esquema es una cuarta parte, la mitad, o lo que corresponda.

Los requisitos llegan en tebibytes cuando salen de un sistema que ya está en marcha: un catálogo de copias de seguridad, el tamaño de una base de datos, un pool que se va llenando. Convertirlos antes de comprar es el paso que evita quedarse corto. Veinte tebibytes de datos exigen 21,99 TB de capacidad bruta, así que una compra de 22 TB los cubre justo y una de 20 TB se queda dos terabytes por debajo antes de escribir un solo bloque de paridad.

Sumar las pérdidas en el orden correcto mantiene la lista de la compra honesta: convertir a decimal primero, dividir después entre la fracción que deja el esquema de redundancia, y añadir por último el margen de seguridad. Un requisito de 20 TiB con paridad simple sobre cuatro discos exige 21,99 TB útiles, es decir 29,3 TB en bruto, y cuatro discos de 8 TB son el conjunto más pequeño que lo cubre. Hacer la conversión de unidades al final es como esa cuenta acaba saliendo, por error, en cuatro discos de 6 TB.

El software de almacenamiento suele mostrar dos totales distintos y no coinciden. Los comandos a nivel de pool tienden a mostrar la capacidad bruta, incluido el espacio que ocupará la paridad, mientras que los del sistema de archivos muestran lo que realmente se puede escribir. En un conjunto raidz la diferencia es la cuota de paridad, y quien compara la salida de una herramienta con la de otra puede perder la capacidad de un disco entero por leer mal la etiqueta, no por ninguna pérdida real.

La comprobación que resuelve la duda es convertir ambas cifras a terabytes decimales y compararlas con los discos instalados físicamente. La cifra bruta debería quedar dentro de un punto porcentual de la suma de las capacidades de las cajas; la útil debería ser la bruta menos el coste de la redundancia. Si ninguna coincide, el problema es de configuración, no de unidades, y conviene encontrarlo antes de llenar el array.

La discrepancia se acumula, un factor de 1,024 por cada prefijo. Un kibibyte queda un 2,4 % por encima de un kilobyte, un mebibyte un 4,9 % por encima de un megabyte, un gibibyte un 7,4 % por encima de un gigabyte y un tebibyte un 9,95 % por encima de un terabyte. El escalón de los tera no tiene nada de especial salvo que es el cuarto, y los errores se han ido multiplicando desde el primero.

Por eso la planificación de capacidad falla a escala de array y casi nunca a escala de archivo. Mezclar las unidades en un documento cuesta unos pocos bytes que nadie nota. Mezclarlas en un pool de dieciséis terabytes cuesta 1,45 TB, más de lo que la mayoría reserva como margen, y el error aparece meses después como un pool que se llena más rápido de lo que predecía la curva de crecimiento.

Los sistemas de archivos copy-on-write se ralentizan de forma notable al acercarse al límite, y la recomendación habitual es mantener el uso por debajo del ochenta por ciento en un pool con escritura constante. Esa reserva se descuenta después de todas las demás pérdidas, así que los 10,91 TiB útiles de cuatro discos de 4 TB con paridad simple se quedan, en la práctica, en 8,73 TiB, es decir 9,6 TB. La distancia entre la factura y la cifra con la que realmente se trabaja es, para entonces, considerable, y no hay ningún fallo detrás.

Dejar la cadena por escrito en el plan de capacidad es lo que evita que la discusión se repita: bruto decimal, bruto binario, útil tras la paridad, disponible tras el margen. Cuatro cifras, cada una derivada de la anterior, cada una con su unidad indicada. Un plan que solo conserva la primera y la última invita a pensar que han desaparecido siete terabytes.

Los esquemas en bandas o con paridad trabajan con unidades del mismo tamaño, así que un conjunto formado por discos de capacidad distinta suele usar la del disco más pequeño para todos los miembros. Añadir un disco de 12 TB a un conjunto de discos de 4 TB aporta 4 TB y deja los 8 restantes sin usar, y ninguna conversión de unidades lo revela desde el total del pool: aparece como una capacidad que ha crecido menos de lo que sugería la factura.

Las estrategias de ampliación difieren en cómo aprovechan ese exceso, y algunas pueden usarlo tratando el array como varios grupos. La cifra que conviene calcular antes de comprar es lo que el esquema va a reclamar realmente de cada disco, en terabytes decimales, y convertir la suma una sola vez. Convertir primero y razonar sobre el esquema después produce un número binario que describe una configuración que nadie va a montar.