Convertir GiB a TiB

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.

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

Los discos se venden en terabytes decimales y los conjuntos se cuentan en unidades binarias, así que lo primero que le pasa a una compra es un recorte del diez por ciento que en realidad no es un recorte: un disco de 4 TB contiene exactamente 4.000.000.000.000 bytes tal como anuncia la caja, que son 3.725,29 GiB, o 3,638 TiB. Ocho de esos discos son 29.802 GiB, 29,10 TiB, y la factura dice 32 TB. No se perdió nada entre esas dos cifras; son los mismos bytes contados en dos bases distintas.

La segunda conversión sí quita capacidad de verdad, y llega después: la paridad o el espejo, la reserva que se guarda el sistema de archivos, y el techo de llenado que cualquiera con sentido común respeta. Mantener las dos separadas es lo que hace verificable un plan de capacidad: primero la cifra bruta en tebibytes, después cada descuento con su razón, en vez de un único número un 40 % por debajo de la factura sin explicación.

Esta es la fuente más habitual de una cifra en gibibytes que no cuadra. zpool list informa del tamaño bruto de los discos, paridad incluida, porque esa es la vista de la capa que administra el conjunto. zfs list informa de lo que la capa de datos puede almacenar realmente, sin la paridad. En un conjunto raidz2 de ocho discos, el primero mostrará más o menos un tercio más que el segundo, y ambos están en lo correcto.

La regla que se deriva de esto es tomar la cifra de la capa que corresponda a la pregunta. Planificar cuántos datos caben es una pregunta de zfs list. Comprobar si un disco de repuesto es suficientemente grande es una pregunta de zpool list. Convertir la equivocada a tebibytes y meterla en un plan produce un conjunto que se llena un tercio antes de lo previsto.

El cálculo principal es sencillo. Un espejo deja la mitad. RAID 5 y raidz1 dejan n − 1 discos de datos. RAID 6 y raidz2 dejan n − 2. Ocho discos de 3.725,29 GiB en raidz2 dan seis discos de datos, 22.351 GiB, 21,83 TiB; los mismos ocho como cuatro pares en espejo dan 14.901 GiB, 14,55 TiB, con un comportamiento de reconstrucción mucho mejor.

El relleno («padding») quita una parte más que la cuenta principal no ve. ZFS asigna en unidades derivadas del tamaño de sector, así que los registros que no dividen exactamente entre los discos de datos dejan huecos, y el efecto es peor con tamaños de registro pequeños en conjuntos anchos. Para un servidor de archivos con el tamaño de registro por defecto la pérdida es pequeña; para un conjunto que aloja una base de datos con registros de 8 KiB puede llegar a una quinta parte de la capacidad nominal, algo que conviene calcular antes de montar el conjunto, no después de descubrirlo.

Un sistema de archivos de copia en escritura no puede liberar un archivo sobrescribiendo un bit en su sitio; tiene que escribir metadatos nuevos, y eso requiere espacio libre. Un conjunto que llegara a cero espacio libre exacto se quedaría sin forma de borrar nada, un estado sin salida. ZFS lo evita reservando una fracción -un treintaidosavo del conjunto por defecto- que las escrituras normales no pueden tocar.

En un conjunto de 32 TiB eso son alrededor de 1 TiB apartados, y no aparece como espacio libre en la cifra que ve el usuario. Es una proporción fija, no una cantidad fija, así que crece con el conjunto, y es uno de los descuentos que debería figurar explícitamente en cualquier plan de capacidad.

El rendimiento de asignación en un conjunto de copia en escritura empeora a medida que el espacio libre se fragmenta, y lo hace de forma brusca, no gradual. El asignador tiene que buscar más para encontrar espacio contiguo, las escrituras quedan dispersas y la lectura sufre porque los datos quedaron esparcidos. La orientación habitual es planificar al ochenta por ciento para un conjunto de uso general.

Eso convierte 32 TiB útiles en unos 25,6 TiB de capacidad de planificación, y tratar la diferencia como un margen para gastar en un trimestre exigente es cómo un conjunto termina lento y difícil de recuperar. Convertir el total de gibibytes a tebibytes y aplicar el techo en el mismo paso deja una sola cifra sobre la que planificar; dejar la cifra bruta en el plan invita a que alguien la use.

Un conjunto no crece en cualquier cantidad. Añadir capacidad significa sumar otro vdev de la misma forma, o sustituir cada disco de uno existente por otro más grande y dejar que se expanda cuando el último termine. Versiones recientes de ZFS permiten añadir un solo disco a un vdev raidz, pero los datos ya existentes conservan su proporción de paridad anterior hasta que se reescriben, así que la cifra útil se mueve menos de lo que sugiere la aritmética simple.

La consecuencia para planificar es que el incremento de crecimiento es grande y conocido de antemano. Un vdev raidz2 de ocho discos de 4 TB añade 21,83 TiB de una vez, así que un plan que va a superar su capacidad en año y medio tiene delante una decisión de compra con un tamaño discreto, no una tasa continua. Calcular ese incremento en tebibytes con tiempo suele resolver de un vistazo si el siguiente paso es un vdev o dos.