Convertir B a MiB

Un byte son ocho bits, cosa que no siempre estuvo clara: los primeros ordenadores usaron seis, siete o nueve. Se impuso el ocho porque en él cabe un carácter y porque la cifra se parte en mitades limpias.

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

En este sentido la cuenta es una división, y por un número entero: 1.048.576 de estas caben en un mebibyte sin que sobre nada. Lo incómodo es solo que los resultados salen en fracciones —un tercio de mebibyte, 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 MiB son 1.024 de la unidad de debajo; un MB, 1.000. En esta página eso es la diferencia entre 1048576 B y 1000000 B —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 1000000 B donde la caja ponía 1048576 B. 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 recuento de bytes es el número fiable de este intercambio. Sale de una llamada al sistema de archivos o de una cabecera de longitud, no tiene ambigüedad de unidad y es contra lo que el programa acabará comparando. La cifra en MiB es una comodidad humana puesta encima, y todos los problemas de este sentido nacen de tratar la comodidad como la fuente de verdad y reconstruir después el número exacto a partir de ella.

Así que haz la conversión en el orden que mantiene mandando al recuento de bytes: divide entre 1.048.576, decide a qué redondeas y vuelve a multiplicar para confirmar que el límite escrito sigue admitiendo el archivo que mediste. Ese último paso lleva segundos y atrapa toda la clase de errores para la que existe esta página, porque un límite no es correcto cuando tiene buen aspecto, sino cuando el archivo pasa.

Un archivo de 10.486.000 bytes son 10,0002 MiB. Escrito en un tope de subida como «10m» resulta que ya es mayor que el límite y será rechazado, y el mensaje de error dirá que el archivo es demasiado grande para un límite que quien lo configuró creía exactamente de su tamaño. Redondear hacia abajo es la costumbre por defecto y, para una cota superior, es siempre la equivocada: la cota tiene que ser al menos igual de grande que lo mayor que pretende admitir.

El caso simétrico es una reserva y no un tope. El espacio apartado para una caché, para un búfer de registro o para un archivo preasignado tiene que redondear hacia abajo, porque redondear hacia arriba promete una capacidad que no existe y el déficit aparece más tarde, con carga, como un fallo de escritura. Una sola pregunta decide la dirección cada vez: si este número se equivoca por un byte, ¿prefiero que sobre un poco o que falte un poco?

Buena parte de la configuración acepta un sufijo, y el sufijo casi nunca dice a qué sistema pertenece. nginx lee k como 1.024 y m como 1.048.576, así que client_max_body_size 10m son 10.485.760 bytes. La máquina virtual de Java hace lo mismo con -Xmx y -Xms. GNU dd separa los dos casos de forma explícita: bs=1M son 1.048.576 y bs=1MB son 1.000.000, y la misma orden produce archivos distintos según cuál se escriba.

Kubernetes es el ejemplo del que conviene aprender, porque se niega a adivinar. Mi, Gi y Ti son las cantidades binarias y M, G y T las decimales, las dos formas son válidas en un manifiesto, y un límite de memoria de 512M es un 4,6 por ciento menor que uno de 512Mi —o, dicho al revés, 512Mi es un 4,9 por ciento mayor que 512M. Nada avisa: el manifiesto se aplica, el pod arranca y el límite no está donde se pretendía.

Un mebibyte es 2 elevado a 20, y por eso aparece como el tamaño natural de cosas que reserva un núcleo. Las páginas son de 4 KiB, las páginas grandes suelen ser de 2 MiB, y un búfer dimensionado a una potencia de dos encaja con todas ellas sin dejar resto al final. Elegir 1.000.000 de bytes para ese mismo búfer no está mal: es un número que el asignador de debajo tendrá que redondear igualmente, de modo que el encaje se paga en otro nivel o en una página a medias.

La consecuencia práctica es que los valores binarios se propagan. Si el tamaño de bloque es una potencia de dos, el tamaño de parte es múltiplo del bloque y el límite es múltiplo de la parte, todo divide exacto y ninguna etapa se queda con una unidad incompleta. Basta meter una cifra decimal en esa cadena para que todas las etapas de debajo empiecen a producir restos, lo que es una ineficiencia pequeña y una fuente grande de confusiones de una unidad.

Subir un objeto grande por partes es donde estos números dejan de ser cosméticos. Un tamaño de parte elegido en unidades binarias parte el archivo en un número entero de partes completas más un resto, y el número de partes está limitado, así que la parte tiene que ser lo bastante grande como para que el objeto quepa dentro de ese tope. Deducirlo de una cifra en MiB redondeada en lugar de del recuento de bytes es como una subida acaba fallando en la parte 10.001 después de haber transferido casi todo.

La comprobación es aritmética y conviene hacerla antes de la transferencia y no durante. Divide el tamaño exacto del objeto en bytes entre el tamaño de parte en bytes, redondea hacia arriba y confirma que el resultado cae dentro del límite del proveedor. Si queda justo, sube el tamaño de parte en lugar de confiar: el fallo llega al final de una subida larga y, para entonces, el dato de diagnóstico útil es un número que podrías haber calculado de antemano.

Mostrar 10,5 MiB está bien. Guardar 10,5 MiB y reconstruir después el recuento de bytes no lo está, porque la presentación ha tirado todo lo que había por debajo de una décima de mebibyte —más de cien mil bytes— y no hay forma de recuperarlo. Los manifiestos, los listados de sumas de verificación y los registros de auditoría deben llevar el recuento de bytes y derivar la cifra amable en el momento de mostrarla, en ese orden, para que el número exacto sobreviva a cada ida y vuelta por un informe.

La misma regla vale para las comparaciones. Dos objetos que se muestran los dos como de 4,2 MiB pueden diferir en cincuenta mil bytes, y una comprobación de duplicados o de desviación escrita contra el valor mostrado los dará por idénticos. Todo lo que decide una igualdad —sincronización, verificación de copias, validación de caché— compara recuentos de bytes, y la cifra en MiB aparece después, en beneficio de quien lea el registro.

El error más caro disponible en esta página no es el 4,9 por ciento que separa MB de MiB: es el factor de ocho que separa bytes de bits. El almacenamiento y los tamaños de archivo se cuentan en bytes; el caudal se da en bits por segundo, y por eso una conexión de 100 Mb/s entrega como mucho 12,5 MB/s y bajar por ella un archivo de 500 MiB lleva alrededor de cuarenta segundos y no cinco.

La convención que los distingue es la B mayúscula para bytes y la b minúscula para bits, y se respeta lo suficiente como para fiarse de ella y se incumple lo suficiente como para comprobarla. Cuando una cifra parece ocho veces mayor o menor de lo que debería, eso es lo primero que hay que mirar, antes que cualquier pregunta sobre qué mil quiso decir alguien. Conviene revisarlo en cualquier número copiado de un esquema de red o de una ficha de fabricante, donde el bit es la unidad de la casa y el byte es la excepción.