Convertir TB a KiB

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 kibibyte son exactamente 1.024 bytes. El nombre se introdujo en 1998 para que «kilobyte» pudiera volver a significar 1.000, aunque la costumbre nunca llegó a imponerse del todo.

En este sentido la cuenta es una multiplicación, y por un número entero: un terabyte son 976.562.500 kibibytes, exactamente, y 976.562.500 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 KiB son 1.024 de la unidad de debajo; un kB, 1.000. En esta página eso es la diferencia entre 0 TB y 0 TB —un 2,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 2,4 %. Un disco vendido en kB 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 TB donde la caja ponía 0 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.

Nada almacena un fichero byte a byte. El espacio se entrega en bloques, y en casi cualquier sistema de archivos moderno un bloque son 4 KiB, porque ese es el tamaño de página de memoria de las arquitecturas sobre las que corre y un bloque que coincide con una página no hay que partirlo. La lectura útil de un terabyte, por tanto, no es 1.000.000.000.000 de bytes sino 244.140.625 bloques, y cualquier pregunta sobre qué cabe vuelve a ese recuento.

La división sale exacta, cosa poco habitual en esta familia y que merece la pena notar: un billón contiene una potencia de dos suficientemente grande, así que un terabyte son 976.562.500 KiB clavados y 244.140.625 bloques sin resto. La mayoría de las conversiones entre los dos sistemas terminan en un decimal largo; esta termina en un entero con el que se puede seguir operando.

Un fichero ocupa bloques enteros, de modo que su último bloque queda a medio llenar. Promediado sobre una colección realista el desperdicio ronda medio bloque por fichero, algo así como 2 KiB cada uno. Eso es invisible en una fototeca y enorme en un buzón de correo: un millón de ficheros pierde unos 2 GiB y cien millones pierden unos 200 GiB, la quinta parte del terabyte antes de que nada haya ido mal.

Lo peligroso es la proporción, no la cifra absoluta. Los ficheros muy por encima del tamaño de bloque pierden una fracción de punto porcentual; los que están en 4 KiB o por debajo pierden la mitad de su espacio o más, así que un directorio de ficheros de 1 kB guarda un terabyte de contenido en cuatro terabytes de bloques. Cualquier estimación de cuánto va a ocupar una colección necesita conocer la distribución de tamaños además del total.

En la familia ext el número de inodos se decide al crear el sistema de archivos y después no se puede cambiar. La proporción por omisión asigna un inodo cada tantos bytes, algo generoso para un uso corriente y claramente insuficiente para un volumen que va a guardar centenares de millones de ficheros pequeños. Cuando se agotan, las escrituras fallan con un error de espacio mientras la cifra de espacio libre sigue teniendo buen aspecto, y ese es uno de los fallos más desconcertantes que produce un sistema de archivos.

Se evita en el formateo y sale caro después, porque cambiar el número de inodos significa rehacer el volumen. Si un volumen va a alojar una cantidad muy grande de objetos pequeños, ese número se elige a conciencia a partir de una estimación del recuento de ficheros en lugar de dejarlo por omisión, y la estimación es la misma aritmética de bloques de arriba aplicada al número esperado de ficheros y no a su tamaño total.

Por debajo del sistema de archivos el dispositivo tiene su propia unidad. Los discos pasaron de sectores de 512 bytes a sectores físicos de 4 KiB, y muchos presentan sectores lógicos de 512 sobre sectores físicos de 4 KiB por compatibilidad. Cuando una partición empieza en un desplazamiento que no es múltiplo del sector físico, cada bloque del sistema de archivos queda a caballo entre dos, y cada escritura se convierte en una lectura y reescritura de ambos.

El efecto es una pérdida de rendimiento y no de capacidad, y en escritura puede ser considerable. Las herramientas de particionado actuales alinean a 1 MiB por omisión y el problema prácticamente ha desaparecido, pero sobrevive en tablas de particiones creadas hace mucho y copiadas de máquina en máquina, y merece una comprobación en cualquier volumen que rinda por debajo de lo que su hardware permitiría.

Planificar la capacidad de un almacén con muchos objetos son en realidad dos presupuestos simultáneos. El presupuesto de bytes pregunta si el contenido cabe; el de objetos pregunta si caben los recuentos de bloques y de metadatos. Un terabyte puede alojar un solo fichero o, en el límite de bloques, 244 millones, y todo lo que hay entre esos dos extremos tiene un coste de metadatos distinto, un tiempo de copia de seguridad distinto y un tiempo de recuperación distinto.

El segundo presupuesto es el que se olvida, porque no aparece en ninguna cifra suelta de un panel. Un volumen al cuarenta por ciento de su capacidad en bytes puede estar lleno a efectos prácticos —sin inodos, o gastando todo su tiempo en metadatos— y el indicador de espacio libre que todo el mundo mira lo describirá como holgado hasta el momento exacto en que una escritura falle.

Este par es uno de los pocos sitios donde los dos sistemas están obligados a compartir frase. La capacidad viene de un fabricante y es decimal porque así se venden los discos; el tamaño de bloque viene de un núcleo y es binario porque así se pagina la memoria. Ninguno de los dos lados va a moverse, de modo que cualquier cálculo sobre qué cabe cruza entre ellos exactamente una vez y conviene que lo haga a propósito.

La costumbre que lo mantiene ordenado es pasar a bytes en la frontera y quedarse ahí: capacidad en bytes, tamaño de bloque en bytes, tamaños de fichero en bytes, y dividir. Así todas las cifras intermedias están en la misma unidad y ningún paso tiene que recordar en qué sistema venía. Convertir a una unidad legible es una decisión de presentación que se toma después de la aritmética, nunca durante.

Los números de esta página solo sirven por adelantado, porque casi ninguna de las decisiones que informan se puede revisar sin rehacer el volumen. Tamaño de bloque, número de inodos y alineación se fijan en la creación. Una estimación de diez minutos —recuento de ficheros esperado, distribución de tamaños esperada, demanda resultante de bloques e inodos— es la diferencia entre un volumen que aguanta años y otro que hay que migrar cuando se llene de una forma que nadie esperaba.

Con una versión aproximada basta para decidir. Si el recuento previsto está en unos pocos millones y los tamaños medios quedan holgadamente por encima de 4 KiB, los valores por omisión sirven y no hay nada que pensar. Si el recuento se va a los centenares de millones, o el fichero medio es más pequeño que un bloque, los valores por omisión no valen y la aritmética anterior dice en cuánto. Dejar la estimación escrita junto a la orden de formateo compensa el minuto extra, porque quien mire el volumen después querrá saber si sus parámetros se eligieron o se heredaron.