Convertir MiB a TB

Un mebibyte son 1.024 kibibytes, es decir 1.048.576 bytes. Las herramientas de Linux y las cifras de memoria se refieren casi siempre a esto, aunque escriban «MB».

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.

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

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 MiB son 1.024 de la unidad de debajo; un MB, 1.000. En esta página eso es la diferencia entre 0 TB y 0 TB —un 4,9 %—, 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 4,9 %. Un disco vendido en MB 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.

Los agentes informan en mebibytes porque es lo que cuenta la máquina, y las facturas van en terabytes decimales porque así se vende la capacidad. Entre las dos hay una suma que parece trivial y que es donde se tuerce el informe de una flota: un millón de MiB son 1.048.576.000.000 bytes, es decir 1,049 TB y no 1. Multiplicado por un parque real, el informe y la factura se separan casi un cinco por ciento.

La discrepancia se comporta mal porque escala exactamente con el total. Nunca es un desfase fijo que alguien pueda localizar y restar; es siempre el mismo porcentaje, así que parece un recargo sistemático y no un error de unidad. Por eso este fallo concreto acaba escalado al proveedor más veces de las que se encuentra en la agregación.

Cuadrar solo es posible en una unidad que las dos partes entiendan igual, y ni el TB ni el MiB lo son mientras nadie diga cuál quiere decir. El byte sí. Expande a bytes el total de la monitorización, expande a bytes la cantidad facturada y compara esos dos números; si ahora coinciden dentro de la ventana de medición, nunca hubo un problema de facturación y toda la diferencia estaba en la etiqueta.

Cuando siguen sin coincidir, el resto merece leerse en lugar de descartarse. Una factura de almacenamiento suele contar cosas que un panel de uso no muestra: instantáneas, réplicas, cargas multiparte sin terminar, objetos borrados todavía dentro de un periodo de retención. Todo eso produce una diferencia con forma —aparece en momentos concretos, no es un porcentaje fijo—, y esa forma es justamente lo que la distingue de un error de unidad, que es el 4,86 % de todo, siempre.

Convertir la cifra de cada máquina a terabytes y sumar los resultados introduce un redondeo por máquina, y con una flota suficientemente grande esos redondeos son una cantidad visible aunque cada uno sea despreciable. Una sola multiplicación aplicada a un total entero exacto no puede desviarse; varios miles de divisiones pequeñas aplicadas antes de la suma, sí.

La misma regla vale para el almacenamiento intermedio. El total en bytes de una flota es un entero grande y debería seguir siendo un entero durante toda la agregación, en lugar de convertirse en un decimal que promedia, redondea y formatea por el camino. Donde haya que transportarlo por un formato de documento sin tipo entero exacto a esa magnitud, llévalo como cadena y vuelve a interpretarlo en el punto en que se compara.

Una cadena tiene tres puntos en los que el criterio puede darse la vuelta, y los tres parecen inofensivos. El exportador elige qué emite, y los que se portan bien emiten bytes en bruto con un sufijo que lo dice. La agregación elige si divide, y suele hacerlo con una constante escrita a mano. La capa de presentación elige un formato, y su elección vive en una definición de panel que no lee nadie.

El que hay que auditar primero es el del medio, porque es el único donde una constante equivocada se vuelve permanente. Una regla de registro que divide entre 1.000.000 para producir megabytes y que luego se muestra como MiB ha dejado un 4,86 % de error dentro de datos ya guardados, y todo informe construido encima lo hereda. Una presentación se corrige con efecto retroactivo; un agregado almacenado, no. La auditoría es corta: busca cada constante de las reglas de registro, compárala con la unidad con la que se etiqueta su salida y deja la respuesta escrita al lado de la regla.

Una previsión arrastra el error de su cifra de partida. Seis meses al diez por ciento mensual convierten una subestimación del 4,86 % en una subestimación del 4,86 % de un número casi el doble de grande, que en términos absolutos es la diferencia entre encargar la capacidad correcta y encargar visiblemente menos de la necesaria. El porcentaje no crece; crece la cantidad a la que se aplica.

La defensa es prever en bytes y convertir solo al presentar, igual que en la agregación. Ayuda además dejar el supuesto escrito dentro de la propia previsión: una línea que diga que las cifras son terabytes decimales derivados de recuentos de bytes ocupa un renglón, y es la que permite a alguien comprobar el número dentro de seis meses en lugar de rehacerlo.

En la práctica «TB» a secas es ambiguo, diga lo que diga la norma, porque una parte apreciable del software escribe TB y quiere decir tebibytes. «TiB» no es ambiguo, y una cifra con una i dentro ya ha dicho todo lo que hacía falta. Cuando el destinatario no vaya a reconocer el TiB, lo que funciona es la cifra decimal con el recuento de bytes al lado: nadie puede malinterpretarlo y cualquiera puede comprobarlo.

En un informe periódico la etiqueta pertenece a la plantilla y no a cada edición, para que no la pierda quien prepare la siguiente con prisa. Un pie que indique la unidad y su definición cuesta una línea y elimina el motivo más frecuente de que alguien vuelva a calcular por su cuenta una cifra de capacidad, que es exactamente lo que el informe existía para evitar. Esa misma línea es la que permite a una auditoría o a un departamento financiero comprobar el número por su cuenta.

Un millón de mebibytes es algo más de un terabyte —un cinco por ciento más—, así que la versión mental consiste en mover la coma seis lugares y añadir un veinteavo. Cuatro millones y medio de MiB son 4,5 más unos 0,22, o sea unos 4,72 TB frente a 4,7186 exactos. Con eso basta para cazar un error de un orden de magnitud y una conversión olvidada, que son los dos errores que importan.

La comprobación equivalente en sentido contrario es que un terabyte decimal son unos 954.000 mebibytes. Cualquier cifra que declare un terabyte a partir de un millón de MiB, o un millón de MiB a partir de un terabyte, ha tratado los dos sistemas como intercambiables, y el cinco por ciento que ha soltado es el mismo que no va a cuadrar con la factura más adelante. Las dos comprobaciones se tardan más en describir que en hacer.