Convertir TiB a kB

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

En este sentido la cuenta es una multiplicación, y por un número entero: un tebibyte son 1.099.511.628 kilobytes, exactamente, y 1.099.511.628 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 1099511627,776 kB y 1000000000 kB —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 1000000000 kB donde la caja ponía 1099511627,776 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.

Un tebibyte son 1.099.511.627.776 bytes, es decir 1.099.511.627,776 kilobytes decimales: en números redondos, mil cien millones de piezas de un kilobyte. Con líneas de registro de 2 kB caben unos 550 millones; con documentos de 20 kB, unos 55 millones; con filas de 512 bytes, unos 2.200 millones.

Esas cifras no dicen nada por sí solas y lo dicen todo en cuanto se ponen al lado del ritmo de generación. Un sistema que produce cincuenta millones de eventos al día de 2 kB cada uno escribe unos 100 GB diarios, así que llena un tebibyte en once días. La conversión de unidades es el paso corto; el ritmo es el dato que casi nunca está medido y que decide el resultado.

Dimensionar retención consiste en tres números y una división: tamaño medio del elemento, elementos por día y días que hay que conservar. Cuarenta gigabytes diarios durante treinta días son 1.200 GB, es decir 1,09 TiB, y ahí acaba la aritmética. Lo que la complica es que los tres números son estimaciones y ninguno es estable.

La costumbre que sostiene el cálculo es medir el caudal en lugar de suponerlo: mirar cuánto ocupa un día real ya escrito, con su compresión y su sobrecarga incluidas, y multiplicar. Un día medido vale más que un cálculo perfecto sobre un tamaño de registro estimado, porque incorpora de golpe todo lo que el cálculo se dejaría fuera.

Los registros de texto se comprimen mucho, porque repiten marcas de tiempo, nombres de servicio, direcciones y plantillas de mensaje. Un factor de tres a cinco es corriente en registros estructurados y no es una promesa: depende del contenido, del algoritmo y del tamaño del bloque que se comprime junto. Frente a eso, el 2,4 % que separa el kilobyte del kibibyte es irrelevante y no merece ni mencionarse en el mismo cálculo.

Lo que sí conviene fijar es en qué punto se mide. Un caudal medido antes de comprimir y una capacidad medida después no se pueden dividir entre sí, y esa mezcla es el error más frecuente en un dimensionado de retención: da un resultado optimista por el mismo factor de la compresión, es decir tres o cuatro veces más días de los que habrá.

Un registro de un kilobyte casi nunca ocupa un kilobyte en disco. Alrededor hay índices, que en un sistema de búsqueda pueden pesar tanto como los datos; hay réplicas, que multiplican el total por el factor de replicación; y hay las estructuras del propio motor, que consumen espacio proporcional al número de elementos y no a su tamaño.

Por eso el dimensionado se hace de fuera hacia dentro. Capacidad utilizable, dividida entre el factor de replicación, menos el espacio de índices, menos el margen de trabajo; y solo con lo que quede se divide entre el tamaño del elemento. Hacerlo en el orden inverso —contar registros primero y aplicar factores después— produce una cifra que parece más precisa y describe una configuración que no existe.

La respuesta exacta de esta conversión, 1.099.511.627,776 kB, tiene una precisión que ningún dimensionado de retención puede aprovechar. El tamaño medio del elemento se conoce con un margen del diez o el veinte por ciento, el caudal varía por días de la semana y por incidentes, y la compresión cambia cuando cambia el formato de los mensajes.

Lo razonable es trabajar con dos cifras significativas y guardar la exactitud para donde sí decide: un límite escrito en un fichero de configuración, una cuota, una comprobación automática. La regla no es «redondear siempre» ni «no redondear nunca», sino redondear en los informes y ser exacto en los campos que una máquina va a leer.

Cuando alguien hereda una hoja de cálculo, lo primero que hay que averiguar es en qué sistema estaba pensada. Los indicios son fiables: los números redondos en 1.024, 2.048 o 4.096 delatan un origen binario; los redondos en 1.000, 500 o 250 delatan uno decimal. Una capacidad de 1.100 GB al lado de un tebibyte es la huella de una conversión hecha bien; una de 1.000 GB, la de una hecha por costumbre.

El desvío entre las dos versiones es del 9,95 %, que sobre un dimensionado de retención se traduce directamente en días. Treinta días planificados sobre la conversión cómoda son veintisiete de verdad, y esos tres días son justamente los que faltan cuando hay que revisar hacia atrás lo que ocurrió durante un puente.

Casi ningún motor libera el espacio en el momento de borrar. Marca los elementos, y el espacio vuelve al pool cuando pasa un proceso de compactación o de fusión de segmentos, que suele necesitar espacio libre para trabajar. La consecuencia práctica es incómoda: un sistema al noventa y ocho por ciento de ocupación puede no ser capaz de recuperar espacio precisamente porque no tiene espacio para recuperarlo.

De ahí que el margen no sea un lujo del dimensionado sino parte del mecanismo. Planificar la retención sobre el cien por cien de la capacidad utilizable produce un sistema que funciona hasta el día en que hay que borrar algo, y ese es el día en que hace falta que funcione. Reservar entre un quince y un veinte por ciento para el proceso de limpieza es lo que mantiene la retención en el número que se prometió.