Convertir MiB a KiB

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 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 mebibyte son 1024 kibibytes, exactamente, y 1024 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 MiB son 1.024 de la unidad de debajo; un MB, 1.000. En esta página eso es la diferencia entre 1024 KiB y 976,5625 KiB —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 976,5625 KiB donde la caja ponía 1024 KiB. 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 buen número de límites de Unix se cuentan en kibibytes sin manera de indicarlo en el propio valor. ulimit -s, ulimit -v y ulimit -m van en kibibytes. Las columnas stack, data, memlock y as de /etc/security/limits.conf, también. El --bwlimit de rsync interpreta un número desnudo como kibibytes por segundo. Los bloques de una cuota de disco son kibibytes. En todos los casos el campo guarda un entero y la unidad la fija la documentación, no nada que se pueda teclear.

Por eso esta conversión es una operación de escritura y no de lectura. Sabes que quieres una pila de 8 MiB o un tope de 20 MiB/s; el campo quiere 8192 o 20480; y el único aviso de haberlo hecho mal es un fallo de segmentación, una transferencia a la milésima parte de la velocidad prevista o un límite tan grande que da igual que exista. Multiplica por 1.024 y deja la cifra en mebibytes escrita en un comentario al lado.

Cualquier cifra en mebibytes multiplicada por 1.024 cae en un múltiplo de 1.024, y las que eran potencias de dos caen en otra potencia de dos: 8.192, 16.384, 65.536, 262.144, 524.288, 1.048.576. Encontrar 8192 en un archivo de configuración dice que quien lo escribió pensaba en mebibytes; encontrar 8000 dice que pensaba en megabytes y que el campo se quedó un 2,3 % por debajo de lo que se pretendía.

La diferencia casi nunca importa por sí sola y casi siempre importa sumada. Un límite puesto en 8000 en lugar de 8192 se queda 192 KiB corto, cosa que ningún proceso notará; un búfer dimensionado en 500.000 en lugar de 524.288 repetido por toda una flota es una diferencia de rendimiento medible, e imposible de atribuir después porque no falló nada. Los números redondos en campos binarios son la señal de corrección más barata que existe.

Donde la herramienta acepta un sufijo, usarlo quita la aritmética y explica el propósito de una vez. sort -S 512M, curl --limit-rate 200K, dd bs=4M y rsync --bwlimit=20M se siguen entendiendo un año después, cosa que sort -S 524288 no. El sufijo además sobrevive a que alguien decida duplicar el valor, y un entero multiplicado a mano no suele sobrevivir a eso.

La excepción es todo lo que vaya a leer algo que no sea la propia herramienta. Los sistemas de monitorización, de gestión de configuración y de auditoría comparan estos campos como enteros, y una flota con 524288 en unas máquinas y 512M en otras estropea la comparación. Cuando ese sea el caso, elige la forma entera a conciencia y mantenla, en lugar de dejar que cada equipo registre la que prefirió quien lo instaló.

El caso más claro es el dd de GNU, porque deletrea las dos formas: bs=1K son 1.024 bytes, bs=1KB son 1.000 y bs=1KiB se acepta como sinónimo del primero. Nada en la sintaxis avisa de cuál se ha escrito, y un dd con el sufijo equivocado copia los datos correctos en trozos de un tamaño algo distinto del previsto, lo que casi siempre funciona y de vez en cuando no, cuando el destino es un dispositivo con un tamaño de bloque rígido.

La regla aproximada para el resto es que lo que mide un caudal suele ser decimal y lo que mide memoria suele ser binario, porque la ingeniería de redes se asentó en potencias de diez mucho antes de que el kibibyte tuviera nombre. Un enlace de 100 Mbit son 100.000.000 de bits por segundo y no 104.857.600, así que un límite de ancho de banda deducido de la velocidad del enlace se calcula en decimal y solo después se pasa a los kibibytes que quiere la herramienta.

La pila de 8 MiB por omisión aparece como 8192 porque esa es la unidad que cuenta ulimit -s, y conviene convertirla en vez de copiarla porque la cifra es por hilo. Una máquina virtual de Java o un servidor con un hilo por conexión y varios cientos de hilos reserva ese espacio de direcciones otras tantas veces, lo que en 64 bits es gratis y en 32 bits agota el espacio de direcciones mucho antes que la memoria.

Bajarla es una palanca real de ajuste y un riesgo real. Poner 512 KiB —el campo admite 512— basta para casi todo el código de aplicación y no basta para un analizador muy recursivo ni para nada que ponga un búfer grande en la pila. El fallo es una violación de segmento sin mensaje alguno sobre límites, así que la cifra en mebibytes merece quedar escrita junto al cambio: «0,5 MiB» se explica solo y «512» no.

PostgreSQL declara sus unidades de memoria como kB, MB y GB y las define como binarias, de modo que shared_buffers, work_mem, maintenance_work_mem y wal_buffers son múltiplos de kibibyte con etiqueta decimal. SHOW shared_buffers devuelve el valor en la unidad que le parece más limpia y pg_settings lo guarda en bloques de 8 KiB, así que el mismo ajuste se puede leer como 128MB, como 131072 kB y como 16384 bloques sin que ninguna de las tres esté mal.

MySQL acepta recuentos de bytes con sufijos K, M y G igualmente basados en 1.024, y los informa en bytes. La consecuencia práctica para ambos es que un valor copiado de una guía de ajuste que hablaba de megabytes se queda un 2,4 % corto por cada escalón de prefijo, y un 7,4 % cuando el ajuste llega al tamaño del gigabyte: nunca lo bastante como para notarlo, y siempre lo bastante como para que dos servidores que debían ser gemelos no lo sean del todo.

Multiplicar por 1.024 conserva cualquier fracción sensata: un medio son 512, un cuarto son 256, tres cuartos son 768 y un octavo son 128. Los valores que vienen de un cálculo decimal no sobreviven tan limpios —0,1 MiB son 102,4 KiB y 1,3 MiB son 1.331,2— y el campo va a exigir un entero, así que hay que decidir en lugar de aplazar.

Hacia dónde redondear depende de qué sea el campo. Un límite, un tope o un máximo se redondea hacia abajo, porque la intención es «no más de esto» y pasarse la contradice. Un búfer, una reserva o un mínimo se redondea hacia arriba, porque un búfer que se queda un kibibyte por debajo de una frontera natural puede costar una asignación extra en cada operación. Ninguna de las dos elecciones cambia gran cosa; hacerla a conciencia es lo que evita que en la revisión haya que adivinar cuál se pretendía.