Convertir TiB a GiB

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 gibibyte son 1.073.741.824 bytes, alrededor de un 7 % más que un gigabyte. Windows mide en gibibytes pero los etiqueta «GB», y en eso consiste todo el misterio del espacio que desaparece.

En este sentido la cuenta es una multiplicación, y por un número entero: un tebibyte son 1024 gibibytes, exactamente, y 1024 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 1024 GiB y 931,3226 GiB —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 931,3226 GiB donde la caja ponía 1024 GiB. 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.024 gibibytes exactos, porque las dos unidades salen de la misma potencia de dos: 2⁴⁰ dividido entre 2³⁰. Es la conversión más limpia de toda la familia y la única de este grupo en la que el resultado nunca lleva coma. Un pool de 20 TiB son 20.480 GiB; uno de 48 TiB, 49.152; uno de 7 TiB, 7.168.

Esa cifra en gibibytes es la que sirve para planificar, porque es la unidad en la que se pide cada cosa que va a ocupar el pool. Veinte tebibytes suenan a mucho hasta que se traducen a doscientos volúmenes de cien gibibytes, y entonces la pregunta deja de ser si cabe y pasa a ser cuántos equipos van a pedir uno.

Con aprovisionamiento fino un volumen consume espacio a medida que se escribe, no cuando se crea, así que la suma de los tamaños declarados puede superar con holgura el tamaño del pool. Es una forma muy eficaz de aprovechar capacidad y también la vía más rápida de llenar un pool sin haber creado ni un volumen de más: nadie hizo nada mal, simplemente todos escribieron a la vez.

El número que hay que vigilar, por tanto, es doble: cuánto se ha asignado y cuánto se ha escrito. Un pool de 20.480 GiB con 32.000 asignados está sobrecomprometido en un 56 %, lo cual puede ser perfectamente razonable si el consumo real ronda el 40 %, y es una emergencia latente si ronda el 90 %. La proporción entre asignado y escrito es la que dice cuánto margen queda de verdad.

Un pool con aprovisionamiento fino lleva su propio espacio de metadatos, donde anota qué bloque pertenece a qué volumen. Ese espacio se dimensiona al crear el pool y se consume con el número de bloques asignados, no con los bytes escritos, de modo que muchas escrituras pequeñas y dispersas lo gastan mucho más rápido que unas pocas grandes.

Cuando se llena, el pool deja de admitir escrituras nuevas aunque el espacio de datos siga teniendo sitio, y salir de ahí en caliente es incómodo. Se comprueba con la misma herramienta que informa de la ocupación de datos, en una columna que casi nadie mira, y merece su propia alerta con un umbral más bajo que el de los datos, porque su margen de reacción es más corto.

La capacidad del pool no es la capacidad repartible. Hay que dejar sitio para las instantáneas, que crecen con la cantidad de datos que cambian y no con la cantidad que hay; para el propio margen de trabajo del sistema de archivos; y para el margen de reacción, que es el espacio que permite mover algo cuando aparece un problema. Un pool sin margen convierte cualquier incidente en una emergencia.

Fijar ese apartado como una cifra explícita al principio funciona mucho mejor que dejarlo implícito. De 20.480 GiB, apartar 3.000 y repartir 17.480 es una decisión que se documenta y se defiende; llegar al 85 % de ocupación sin haber decidido nada es la misma situación descubierta por sorpresa. El número exacto importa menos que el hecho de que esté escrito antes del primer volumen.

Un volumen de bloques en la nube se pide en gibibytes enteros y se factura por gibibyte y mes, con el redondeo hacia arriba. Pedir 100,5 GiB cuesta lo mismo que pedir 101, y pedir un tamaño calculado con decimales significa pagar la parte que no se usa desde el primer día hasta que el volumen se elimine.

Como el redondeo es siempre hacia arriba, la costumbre útil es elegir tamaños que ya sean enteros y, mejor, potencias de dos o múltiplos limpios: 64, 128, 256, 512. No ahorran dinero por sí mismos, pero hacen que la suma de los volúmenes sea comprobable a ojo contra el tamaño del pool, y esa comprobación es la que detecta el volumen olvidado que lleva ocho meses cobrándose.

Ampliar un volumen es una operación habitual y en muchos casos se hace en caliente: se agranda el volumen, se agranda el sistema de archivos encima y ahí acaba. Reducirlo es otra cosa: hay sistemas de archivos que no lo permiten en absoluto y otros que exigen desmontar, y en todos los casos supone mover datos con el volumen fuera de servicio.

La consecuencia para el reparto es asimétrica y conviene tenerla presente al elegir el primer tamaño. Empezar pequeño y crecer cuando haga falta es barato; empezar generoso «por si acaso» inmoviliza capacidad que después cuesta trabajo recuperar. Con aprovisionamiento fino el coste de empezar grande es menor, pero no es cero, porque el tamaño declarado sigue contando para el sobrecompromiso.

Un tamaño de volumen que divide el pool sin resto ahorra una clase entera de conversaciones. De 20.480 GiB salen exactamente 80 volúmenes de 256, o 40 de 512, o 160 de 128. Con volúmenes de 100 GiB salen 204 y sobran 80 gibibytes que no dan para otro: un cabo pequeño que no molesta a nadie y que, repetido en cinco pools, es un volumen entero perdido en fragmentos.

No es una regla que haya que obedecer siempre; hay peticiones que solo tienen sentido con un tamaño concreto. Sí es un buen valor por omisión para las plantillas, sobre todo porque un tamaño en potencia de dos es reconocible al leer un listado, y un listado donde todos los tamaños son reconocibles hace que el que no lo es salte a la vista.