Convert GB to MiB

A gigabyte is a billion bytes in the decimal sense used by drive manufacturers, phone plans and video sizes.

A mebibyte is 1,024 kibibytes, or 1,048,576 bytes. Linux tools and memory sizes generally mean this even when they print "MB".

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

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 MiB is 1,024 of the unit below it; one MB is 1,000. On this page that is the difference between 0.001 GB and 0.001 GB — 4.9 % — 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 4.9 %. A drive sold in MB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 0.001 GB where the box said 0.001. 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.

A gigabyte is a billion bytes. A mebibyte is 1,048,576. Divide one by the other and you get 953.67431640625, exactly and with no rounding — a number nobody would guess and everybody has to look up. The instinct is to reach for either 1,000, which is the MB in a GB, or 1,024, which is the MiB in a GiB, and both are wrong here because the pair crosses between the two systems.

The size of the error depends on which wrong number you pick. Using 1,000 overstates by 4.9 percent; using 1,024 overstates by 7.4. On a dashboard that is a slightly wrong line. On a threshold it is an alert that fires at a percentage you did not choose, and on a capacity plan it is the difference between provisioning enough and being 7 percent short at the moment the forecast said you would be comfortable.

Thresholds are usually meant as fractions of something: alert at 80 percent of the disk, page at 90 percent of the memory limit. That intent survives only if the fraction is taken of the allocation in the allocation's own unit and then converted once, at the end. Eighty percent of a gigabyte is 762.9 MiB and ninety percent is 858.3 MiB, and neither is a number anybody types by choice.

What people type instead is 800 and 900, which are round and are not the fractions they were meant to be — 800 MiB is 84 percent of a gigabyte and 900 MiB is 94. The alert still works, it fires later than the runbook says it does, and the discrepancy is invisible because both the rule and the documentation contain plausible round numbers.

Prometheus takes no position on any of this: the convention among its exporters is to record raw bytes with a _bytes suffix and let the presentation layer choose a unit. That is the right design and it moves the decision to the dashboard, where it is made per field, often by whoever built the panel, and rarely written down anywhere the person reading the graph will see.

The practical effect is that two panels on the same dashboard can show the same series 7 percent apart and both be correctly configured. A query returns bytes; one panel formats them in the SI sense and one in the IEC sense; the axes say GB and GiB, or worse, both say GB. When a number on a dashboard has to be compared with a number from anywhere else, check the field's unit setting first rather than the axis label.

Container resources are the place this conversion is done most often and checked least. Kubernetes accepts both systems and distinguishes them properly: Mi and Gi are the binary quantities, M and G the decimal ones. A limit of 1G is 1,000,000,000 bytes; a limit of 1Gi is 1,073,741,824. Both are valid, both apply without warning, and they differ by 7.4 percent.

The trap is a chain where the units change at each link. Capacity is bought in decimal GB, a node is described in GiB, a limit is written in Mi, and a dashboard displays whichever it was configured for. Every conversion in that chain is doable; the failure is doing three of them by eye. Convert everything to bytes once, at the point where the numbers are compared, and let the friendly units be display only.

There is a workable heuristic and it should be treated as a heuristic. Numbers that describe something purchased — a plan, a quota, a bill, a transfer allowance — are almost always decimal, because that is the unit capacity is sold in. Numbers that come from inside a running machine — memory used, page cache, filesystem free space on Linux — are almost always binary, because that is what the kernel counts in.

Where the heuristic runs out, there is a test that does not. Find a quantity you can measure in bytes independently, put it through the console, and see which division reproduces the displayed figure. It takes one observation and it settles the question for that console permanently, which is a better use of five minutes than any amount of reading documentation that may not say.

It does not look like anything, and that is the difficulty. A line 5 percent above where it should be has the same shape, the same trend and the same rate of change as the correct one; nothing about it invites suspicion. The error only becomes visible where the graph is compared with an external figure — a bill, a quota, a second tool — and then it presents as a mystery rather than as a unit problem.

The one visual clue worth knowing is a headroom line that never quite lines up. If a usage series is plotted against a capacity line taken from somewhere else, and the usage plateaus at 93 or 107 percent of the capacity rather than at 100, that ratio is the unit gap rather than a measurement artefact. 1.074 and 0.931 are the two numbers to recognise; 1.049 and 0.954 are their one-step equivalents.

The lasting fix is not getting this conversion right once, it is making it unnecessary the next time. Name variables and metrics for what they hold — a threshold in bytes is a threshold in bytes, whatever it is displayed as — and put the derivation next to any literal that was converted by hand, so a reviewer can check 953.674 without going to look it up.

Where a system has to talk to another one, agree on bytes at the boundary and convert only at the edges. That is the same discipline used for time zones and currency and for the same reason: the ambiguity is not in the arithmetic, which is trivial, but in the number of places somebody has to remember which convention was in force. Reducing that to one place is the whole of the fix. It also gives the next person something to check against: a single documented boundary can be verified in a minute, while a convention applied from memory at six different points cannot be verified at all.