Convert GiB to MB

A gibibyte is 1,073,741,824 bytes — about 7% more than a gigabyte. Windows measures in gibibytes and labels them GB, which is the whole of the missing-space mystery.

A megabyte is a million bytes. Storage manufacturers have always used this decimal meaning, which is why their capacities look larger than what a computer reports.

The factor is 1073.741824, and almost nobody carries that around. Rounded to 1070 it is off by 0.35 % — which stays invisible on small numbers and turns into a whole unit somewhere around 1,000 GiB.

That is the number worth knowing before you round: not the error itself, but where it stops being ignorable. Below that point the shorter factor is the sensible one; above it, use the field above, which never rounds until it prints.

One GiB is 1,024 of the unit below it; one GB is 1,000. On this page that is the difference between 1073.7418 MB and 1000 MB — 7.4 % — and the gap grows at every step up the scale, which is why it is a rounding error on a photograph and a visible chunk of a hard disk.

This is the whole of the missing-storage mystery, and on this page it is worth 7.4 %. A drive sold in GB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 1000 MB where the box said 1073.7418. macOS has counted these in the decimal units since 10.6, which is why the same drive can look two sizes on two machines — nothing is missing and nobody is rounding, the same bytes have two names.

Every other quantity in this category is binary by convention and could in principle have gone the other way. Memory could not. A chip is selected by address lines, and n lines reach exactly 2 to the n locations — ten lines give 1,024, twenty give 1,048,576, thirty give 1,073,741,824. There is no wiring that reaches a round decimal number of locations, so memory capacity is a power of two by construction rather than by anybody's choice.

That is why a module sold as 16 GB holds 17,179,869,184 bytes and nobody objects. The label is a decimal prefix applied to a binary quantity, exactly the practice that causes arguments about hard drives, and here it causes none — because the alternative would be to sell 16 GB of memory containing 16,000,000,000 bytes, which cannot be built. For memory, the binary reading is the only one that describes a real part.

The arithmetic is a multiplication by 1,073.741824: 8 GiB is 8,589.93 MB, 16 GiB is 17,179.87 MB, 64 GiB is 68,719.48 MB. Those are the correct decimal figures and they are almost never what an allocation field wants, because a field asking for memory in MB is usually asking for mebibytes and expecting 8,192, 16,384 and 65,536.

So the first question is not how to convert but which unit the box means. QEMU's memory argument is in mebibytes; most virtualisation interfaces labelled MB behave the same way; the JVM's m suffix is binary too. Where one of them is genuinely decimal, entering the round binary figure hands the process 4.6 percent less memory than intended, which on a tuned heap or a database buffer pool is enough to change behaviour without producing an error anywhere.

Allocate a round binary number and ask the guest what it got. Enter 4,096 into the field, start the machine, and read the memory it reports: a guest showing exactly 4 GiB confirms the field is mebibytes, and one showing 3.81 GiB confirms it is decimal megabytes. The whole test takes a minute and the answer holds for that tool permanently.

It is worth doing once per platform rather than reasoning from documentation, because documentation on this point is frequently written by someone who did not consider the question. The observed behaviour is authoritative and the label is not, which is the same principle as reading a drive's byte count instead of its summary line.

The chain from a host's GiB figure to a process's allocation usually passes through three units and at least one subtraction. The host reports GiB. Something has to be left for the operating system, page cache and any other process. The remainder goes into a field in MB or MiB, and inside the process it becomes a heap with its own overheads on top of the number you gave it.

The reliable way through is to do every step in bytes and convert once at the end, into whichever unit the field turns out to want. Doing it in mixed units invites a subtraction between a decimal figure and a binary one, which produces a number that is neither, and the result is an allocation that is a few percent off in a direction nobody recorded.

A hypervisor will generally let you promise guests more memory in total than the host physically has, on the reasonable assumption that they will not all use their maximum at once. That means an allocation which is quietly 5 percent smaller than intended does not fail at configuration time, does not fail at boot, and does not fail under ordinary load. It fails under the specific pressure the sizing was meant to cover.

When it does fail, the symptom points away from the cause. A guest that swaps, a heap that spends its time collecting, a cache with a worse hit rate than the model predicted — all of these look like tuning problems, and the sizing number in the configuration looks correct because it is the number somebody meant to enter. Checking what the guest actually received is the step that finds it.

Installed memory and available memory are different numbers for reasons that have nothing to do with units. Firmware reserves regions, and on a machine with integrated graphics a block is carved out for the display, so a system with 16 GiB installed may report noticeably less as usable. This is a genuine subtraction of real memory rather than a relabelling, and it is worth separating from the conversion so neither gets blamed for the other.

The two are told apart by the size and shape of the gap. A unit difference is always the same percentage — 4.9 or 7.4, depending on how many steps it crosses — while a hardware reservation is a fixed quantity that does not scale with the total. If the missing amount stays constant as you change the configuration, it is reserved; if it stays a constant fraction, it is arithmetic. That single test separates a hardware question from a units question in about a minute, and it is worth applying before either is investigated further.

Nothing forbids allocating 4,000 MB of memory, and it will work. It will also fail to divide evenly by the page size, the huge page size, and most of the structures underneath it, so every layer rounds slightly and the number you set is never quite the number in effect. A figure of 4,096 MiB passes through all of them unchanged, which makes every subsequent measurement easier to reconcile.

There is a documentation benefit as well. A configuration full of powers of two is self-describing: a reviewer sees 8,192 and knows it is 8 GiB without arithmetic, while 8,590 has to be looked up and is easily mistyped into something plausible. On systems where memory figures are read far more often than they are set, that legibility is worth more than the negligible capacity difference between the two choices. It also makes a review meaningful: a reviewer who can see at a glance that every allocation on a host is a power of two can add them up and compare the total against the installed memory without doing any conversion at all.