Convertir kB a GiB

Un kilobyte son 1.000 bytes cuando lo define un organismo de normalización y 1.024 cuando lo define un sistema operativo. Esta página calcula con 1.000; la unidad de 1.024 se llama kibibyte.

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.

El factor es 0,000001, y casi nadie lo lleva encima. Redondeado a 0,000001 se desvía un 0,14 %, que pasa desapercibido en cifras pequeñas y se convierte en una unidad entera alrededor de 1000 kB.

Ese es el dato que interesa antes de redondear: no el error en sí, sino a partir de dónde deja de ser despreciable. Por debajo de ahí el factor corto es el sensato; por encima, usa el campo de arriba, que no redondea hasta el momento de escribir el resultado.

Un GiB son 1.024 de la unidad de debajo; un GB, 1.000. En esta página eso es la diferencia entre 1073741,824 kB y 1000000 kB —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 1000000 kB donde la caja ponía 1073741,824 kB. 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.

El tamaño de una pieza llega casi siempre en kilobytes decimales. Una línea de registro son 1,2 kB, un registro JSON son 4 kB, un correo sin adjuntos son 15 kB, una tesela de mapa son 30 kB. Todas esas son mediciones de contenido, obtenidas contando bytes y dividiendo entre mil, y quien las produce está pensando en cargas útiles y no en discos.

El presupuesto donde esas piezas tienen que caber lo informa algo completamente distinto. Un volumen, una caché en memoria, el límite de un contenedor o una política de retención se expresan en gibibytes, porque el programa que los informa calcula en potencias de 1.024. Esta conversión se sitúa por tanto en la junta entre una medida de contenido y una medida de capacidad, y tiene que salvar a la vez un prefijo de un millón y una diferencia de sistema del 7,37 %.

En un gibibyte caben 1.073.741,824 kB. La versión aproximada —un millón de kilobytes por gibibyte— se equivoca en un 6,9 % y exagera cuántos gibibytes hace falta reservar para un montón dado de kilobytes. Ese es el lado seguro por el que equivocarse y sigue siendo el número que no conviene apuntar, porque usar 1,074 millones en su lugar no cuesta nada y elimina el error entero.

Para calcular de cabeza es más limpia la forma por pieza que la forma por gibibyte. De una pieza de 1 kB caben unas 1.074.000 en un gibibyte; de una de 4 kB, unas 268.000; de una de 30 kB, unas 35.800. Convertir la proporción en un recuento de cosas en lugar de en un recuento de kilobytes hace mucho más fácil detectar un disparate, porque una cantidad de registros es un número del que el lector ya tiene intuición.

La mayoría de las estimaciones con esta forma empiezan siendo un caudal y no un total, y es en el caudal donde la aritmética se vuelve sorprendente. Un kilobyte por segundo son 86.400 kB al día, es decir 0,0805 GiB, o 29,4 GiB al año. Diez kB/s son 294 GiB al año. Cien kB/s —un solo servicio moderadamente hablador— son 2,87 TiB al año.

El paso que se salta casi todo el mundo es que un caudal indicado por instancia se multiplica primero por el número de instancias y después por la retención. Cuarenta servicios a 10 kB/s con noventa días de retención son 40 × 0,805 GiB al día × 90, es decir 2.898 GiB, o 2,83 TiB, ocupados de manera permanente. Ninguna de las cifras sueltas parecía un problema de almacenamiento y el producto es una estantería.

Conviene decirlo sin rodeos, porque una página sobre una conversión de unidades tiene el incentivo contrario. El 7,37 % que separa la escala decimal de la binaria es real y hay que aplicarlo. También es, en una estimación construida a partir de tamaños por pieza, el cuarto o el quinto motivo de error por tamaño.

Por delante van estos: si el tamaño medido incluía la envoltura y las cabeceras, si el almacén guarda un índice y de qué tamaño, si el dato se replica dos o tres veces, si se comprime y en qué proporción, y si el periodo de retención es el que dice la política o el que está configurado de verdad. Cada uno de ellos es un multiplicador y no un porcentaje, y cualquiera puede duplicar el resultado por sí solo.

Un sistema de archivos entrega el espacio en bloques, normalmente de 4 KiB. Un registro de 2 kB escrito como archivo independiente ocupa 4.096 bytes, así que un millón de ellos son 2 GB de contenido y 3,81 GiB de disco. A 500 bytes por registro la proporción empeora: 0,5 GB de contenido se convierten en esos mismos 4.096.000.000 de bytes en disco, unas ocho veces el tamaño medido.

Esos mismos registros empaquetados en segmentos de registro, en páginas de base de datos o en objetos de un almacén de objetos cuestan su propio tamaño más unos pocos bytes de envoltura, y el redondeo de bloque ocurre una vez por segmento en lugar de una vez por registro. Por eso conviene fijar la disposición del almacenamiento antes que la conversión de unidades: convertir con cuidado y multiplicar después por el modelo equivocado da una respuesta precisa sobre la magnitud que no era.

El texto se comprime bien y las líneas de registro se comprimen muy bien: proporciones de cinco o de diez a uno son lo corriente en texto estructurado con nombres de campo repetidos. Aplicarlo en el punto correcto decide si la estimación se podrá revisar más adelante. Comprima la cifra por pieza, anote qué proporción supuso, multiplique después por la cantidad y convierta al final.

Hacerlo al revés —convertir a gibibytes y dividir luego entre una proporción de compresión— da el mismo número y pierde el rastro. Cuando resulte que el almacén comprime tres a uno y no ocho, quien revise la estimación necesita ver qué cifra se midió y cuál se supuso, y un único número mezclado no se lo cuenta.

El formato útil es una cadena de renglones, cada uno con su propia unidad: tamaño medido por pieza en kB, piezas por segundo, número de instancias, retención en días, proporción de compresión, factor de réplica, y después el total en bytes y por fin en GiB. Siete renglones, y cada uno de ellos es un número que alguien puede discutir por separado.

La alternativa —una cifra única con las cuentas hechas en la cabeza de alguien— no se equivoca más a menudo, pero es imposible de arreglar cuando se equivoca. Las estimaciones de almacenamiento se revisan cada vez que el consumo se aparta de ellas, y las que sobreviven a ese proceso son aquellas en las que la desviación se puede atribuir a un renglón en lugar de a la estimación entera.

Merece la pena decir explícitamente por qué los dos lados de esta conversión usan sistemas distintos, porque no es un capricho. El tamaño de la pieza se obtuvo contando contenido —una carga útil, una fila, el cuerpo de un mensaje— y el contenido no tiene ninguna estructura de bloques natural, así que se cuenta en decimal como cualquier otra medida de una cantidad de cosas. El presupuesto lo produjo algo que reparte espacio: un núcleo, un motor de contenedores, un sistema de archivos, un asignador de memoria. Todos ellos trabajan en potencias de dos porque el hardware que tienen debajo lo hace.

La conversión no es entonces la traducción entre dos convenios arbitrarios, sino el paso de medir un contenido a medir el recipiente donde va, y el recipiente tiene forma. Eso explica también por qué en las piezas pequeñas el redondeo de bloque pesa más que la diferencia de unidad: importa más la forma del recipiente que el nombre de su unidad. Calcular en bytes y aplicar el modelo de almacenamiento de manera explícita mantiene los dos efectos a la vista en lugar de fundirlos en un único coeficiente de conveniencia.