Convertir MB a GiB

Un megabyte es un millón de bytes. Los fabricantes de almacenamiento siempre han contado en decimal, y por eso sus cifras parecen mayores que lo que muestra el ordenador.

Un gibibyte son 1.073.741.824 bytes, alrededor de un 7 % más que un gigabyte. Windows mide en gibibytes pero los etiqueta «GB», y en eso consiste todo el misterio del espacio que desaparece.

El factor es 0,000931, y casi nadie lo lleva encima. Redondeado a 0,00093 se desvía un 0,14 %, que pasa desapercibido en cifras pequeñas y se convierte en una unidad entera alrededor de 1000 MB.

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 GiB son 1.024 de la unidad de debajo; un GB, 1.000. En esta página eso es la diferencia entre 1073,7418 MB y 1000 MB —un 7,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 7,4 %. Un disco vendido en GB 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 1000 MB donde la caja ponía 1073,7418 MB. 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 archivos llegan con etiqueta decimal: una descarga de 700 MB, un vídeo de 1.400 MB, un catálogo que suma 18.000 MB. Los recipientes llegan con etiqueta binaria: una partición de 20 GiB, una imagen de 8 GiB, una cuota expresada tal y como cuenta el sistema de archivos. Saber si lo uno entra en lo otro es una sola multiplicación por 0,000931322574615478515625, y es exacta.

18.000 MB son 16,76 GiB, así que caben en un volumen de 20 GiB con sitio de sobra. La costumbre que falla es dividir entre 1.000 y llamarlo 18 GiB, que en este sentido solo es pesimista: el montón parece mayor de lo que es. Aplicada a la pregunta inversa —dimensionar un volumen para una cantidad conocida de contenido etiquetado en decimal— esa misma costumbre te deja un siete por ciento corto.

Este par cruza tres escalones entre los dos sistemas en lugar de uno, y por eso el número no le suena a nadie. Un escalón es 1.024 frente a 1.000 y da un 2,4 %; dos escalones dan un 4,9; tres, que es lo que abarca de MB a GiB, dan un 7,4 % leído en un sentido y un 6,9 leído en el otro. Una cifra de megabytes pasada a gibibytes es el 93,1 % de la división ingenua, y 0,931 es la constante que conviene reconocer de vista.

Su pareja es 1,074, que es por lo que se multiplica en el camino contrario. Entre las dos explican casi cualquier discrepancia de almacenamiento a esta escala: si una cifra falla en torno a un siete por ciento, es que uno de los dos lados de la comparación cruzó tres escalones en el sistema equivocado, y no hace falta investigar nada más.

El DVD de una capa es el ejemplo cotidiano más limpio porque las dos cifras están impresas donde la gente puede verlas. El disco guarda 4.700.000.000 bytes, que son 4,7 GB según la definición estándar y es lo que dice la caja. El sistema operativo divide entre 1.073.741.824, obtiene 4,377 y lo rotula GB: el mismo disco es 4,7 GB en el envase y 4,37 GB en pantalla sin que por el camino se haya perdido nada.

Por eso una imagen montada para llenar «4,7 GB» con una herramienta que cuenta en binario no se graba: la herramienta cree tener 4,7 de sus propios gigabytes que llenar, que serían 5.050 millones de bytes, y el disco tiene 4.700 millones. El software de autoría que acierta trabaja en bytes de principio a fin, y los que no lo hacían son la razón de que el problema haya resultado tan familiar durante tantos años.

La conversión te dice si caben los bytes; no te dice si caben los archivos, y son dos preguntas distintas. Un sistema de archivos reserva espacio para sus propias estructuras y, sobre todo, guarda cada archivo en bloques enteros —típicamente de 4 KiB—, así que uno de 100 bytes ocupa 4.096 y uno de 5.000 bytes ocupa 8.192. La suma de los tamaños es por tanto siempre una estimación por debajo del sitio que van a llevarse.

Cuánto por debajo depende por completo de la mezcla. Unos pocos archivos grandes de vídeo pierden casi nada, porque solo el último bloque de cada uno queda a medias. Decenas de miles de archivos pequeños pueden perder una fracción considerable: cien mil archivos de un kilobyte de media ocupan unos 400 MB y no 100. Cuando un recipiente se va a llenar hasta el último margen, la cantidad de archivos importa tanto como el total.

Las herramientas de virtualización crean los discos en unidades binarias y muchas interfaces muestran después la lectura decimal del resultado, y de ahí que los tamaños queden tan poco redondos. Un disco creado como 20 GiB son 21.474.836.480 bytes y se muestra como 21,5 GB; uno creado como 20 GB son 18,6 GiB. Los dos existen, los dos son legítimos, y un plan que dé por hecho que son el mismo tamaño se equivoca en lo que ocupa un disco entero sobre un anfitrión grande.

Lo práctico es decidir la capacidad en bytes, crear el disco en la unidad que ofrezca la herramienta y verificar después el recuento de bytes en lugar de la etiqueta. El aprovisionamiento fino añade una consideración más: el tamaño lógico es el que ve el sistema invitado y el archivo físico va creciendo hacia él, así que un anfitrión puede estar sobrecomprometido con mucho margen sin que ninguna cifra de la interfaz parezca rara.

Saca el total en bytes, añade el redondeo a bloques que corresponde al número de archivos previsto, añade el gasto propio del sistema de archivos y convierte al final a la unidad que pida el cuadro de creación. En ese orden, cada margen se aplica a un número cuya unidad se conoce, y la conversión ocurre exactamente una vez y en un sitio donde se puede comprobar. En cualquier otro orden se acaba mezclando un margen de un sistema con un total del otro.

Y deja holgura de verdad, porque un recipiente técnicamente suficiente es un mal sitio donde estar. Los sistemas de archivos se fragmentan y se ralentizan cerca del lleno, algunos necesitan espacio libre para completar operaciones, y cualquier crecimiento del contenido obliga a repetir el ejercicio entero. Entre un diez y un veinte por ciento de margen elimina toda una categoría de trabajo futuro por un coste que suele ser trivial. La excepción es un recipiente cuyo tamaño lo fija algo físico, como un disco óptico, donde no hay holgura que comprar y la única palanca que queda es qué se mete dentro.

La versión mental es dividir entre mil y quitar un siete por ciento: 4.700 MB son 4,7 menos unos 0,33, o sea 4,37 GiB frente a 4,3772 exactos, y 18.000 MB son 18 menos 1,26, es decir 16,74 frente a 16,76. La estimación es buena a una fracción de punto porcentual en todo el rango en el que se usa este par, que basta para decidir si algo cabe con sitio de sobra.

No basta para decidir en el límite, y el límite es justo donde la gente echa mano de ella. Si el total queda a un pequeño porcentaje del recipiente, haz la cuenta exacta y ten en cuenta además el redondeo a bloques, porque a esas alturas lo que separa la estimación de la realidad es más o menos el margen que te queda. La cifra exacta cuesta unos segundos, y la alternativa es descubrir que falta sitio al final de una copia que lleva una hora corriendo.