Convert MiB to GiB

A mebibyte is 1,024 kibibytes, or 1,048,576 bytes. Linux tools and memory sizes generally mean this even when they print "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.

Going this way is a division, and by a whole number: 1,024 of these fit into one gibibyte with nothing left over. The awkwardness is only that the answers come out as fractions — a third of a gibibyte, a twelfth of one — rather than as the round figures the other direction gives you.

Nothing is lost to rounding even so. The division is exact, and if your answer will not sit still as a decimal — 0.0833… and friends — that is the fraction showing through, not an error creeping in.

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 GiB and 0.0009 GiB — 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.0009 GiB 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.

Kubernetes resource quantities accept two families of suffix. The binary set — Ki, Mi, Gi, Ti, Pi, Ei — multiplies by powers of 1,024. The decimal set — m, k, M, G, T, P, E — multiplies by powers of 1,000, with a lower-case kilo, and the m at the front is a milli that exists for fractional CPU rather than for memory. memory: 512Mi and memory: 512M are both valid, differ by 24,870,912 bytes, and produce no warning in either direction.

The 4.9 per cent gap at the mebibyte step widens to 7.4 per cent at the gibibyte step: 4Gi is 4,294,967,296 bytes and 4G is 4,000,000,000. Every tool in the chain will faithfully preserve whichever was written, and the value shown in a dashboard is usually re-formatted into whichever unit that dashboard prefers, so the original suffix is visible only in the manifest itself. Grepping a repository for a bare M or G in a memory field is a five-minute audit worth doing once.

CPU is compressible: a container that asks for more than its limit is throttled and carries on, slowly. Memory is not. When a container's cgroup exceeds its memory limit the kernel's OOM killer terminates a process inside it, the container reports exit code 137, and the pod restarts. There is no gradual degradation and no warning in between, which is why a limit that is 4.9 per cent smaller than intended is not a rounding error but a change in how often a workload dies.

It also means the two suffixes fail asymmetrically. Writing M where Mi was meant makes the limit smaller and the container more likely to be killed — a visible failure that gets investigated. Writing Mi where M was meant makes it larger, which surfaces as nothing at all until the node is overcommitted and the scheduler has been packing on figures that were all slightly generous. The second is the one that costs money quietly.

A JVM started with -Xmx4096m has a 4 GiB heap and a total footprint noticeably larger. Metaspace holds class metadata and is unbounded by default; each thread takes its stack, typically 1 MiB, outside the heap; the JIT's code cache defaults to 240 MiB on 64-bit HotSpot; direct byte buffers used by Netty and most NIO-based servers are native memory; and the garbage collector keeps its own structures. A container limit equal to -Xmx is a container that will be killed.

The usual practice is to give the container 25 to 50 per cent more than the heap, or to stop setting -Xmx at all and let the JVM size itself. Since JDK 10 the runtime reads the cgroup limit and applies -XX:MaxRAMPercentage, which defaults to 25 — conservative enough that a 4Gi container gets a 1 GiB heap unless the percentage is raised. Setting it to 70 or 75 and letting the JVM do the arithmetic removes one of the two numbers that can be wrong.

A node advertised as 16 GiB does not offer 16,384 MiB to pods. Capacity minus kube-reserved minus system-reserved minus the hard eviction threshold gives allocatable, and on a managed cluster the reservation typically runs from a few hundred mebibytes on a small node to well over a gibibyte on a large one. kubectl describe node prints capacity and allocatable side by side, and the difference is the number that decides how many replicas actually fit.

This is where converting to gibibytes earns its keep, because bin-packing arithmetic in mebibytes invites mistakes. Nine replicas at 1,536Mi is 13,824Mi, which is 13.5 GiB, which fits inside 14.6 GiB of allocatable with room for the daemonsets and does not fit if the node reserves more than it looked like. Doing the sum in mebibytes and comparing it to a node quoted in gibibytes is how a cluster ends up one pod short of its intended replica count with no obvious cause.

The request is what the scheduler reserves and the limit is what the kernel enforces, and the relationship between them decides the pod's eviction priority. Equal request and limit gives Guaranteed; a request lower than the limit gives Burstable; neither set gives BestEffort, which is evicted first when a node comes under pressure. The class follows from the two numbers rather than being declared, so a manifest that sets 512Mi and 1Gi has chosen Burstable whether or not anybody meant to.

For memory specifically, the case for setting them equal is stronger than for CPU. A Burstable pod that habitually uses more than its request is scheduled as though it were small and killed as though it were large, and the node it lands on is overcommitted on the strength of a figure nobody checked. Where the working set is known, writing the same gibibyte figure twice is both simpler and more honest than a spread nobody revisits.

The manifest says 1536Mi; Grafana says 1.5 GiB; the cloud console says 1.61 GB; the cost report says 1.6 GB-hours. All four are the same 1,610,612,736 bytes, presented by four tools with different conventions, and only the first two are on the binary side. Reconciling a bill against a manifest means knowing which side each figure is on before comparing them, and the 7.4 per cent gap is large enough that a mismatch looks like a real discrepancy.

The habit that helps is to keep one canonical unit per document. Capacity plans in gibibytes, manifests in whichever of Mi or Gi keeps the number whole, and any figure quoted in a decimal unit labelled as such. A capacity spreadsheet whose column header says GiB and whose numbers came out of a console reporting GB is wrong by a fifteenth and will stay wrong until somebody rebuilds it.

The figure worth converting is the one the workload actually uses, and container_memory_working_set_bytes is the metric the kernel and the OOM killer effectively act on — resident memory less the page cache that can be reclaimed. Taking its peak over a fortnight, adding headroom, and rounding up to a tidy mebibyte or gibibyte figure produces a limit that can be defended; taking the container's RSS or, worse, the JVM's own heap report produces one that cannot.

Round upwards to a power of two where the choice is free. A limit of 1,536Mi is 1.5 GiB and packs neatly into nodes sized in gibibytes; a limit of 1,600Mi is 1.5625 GiB, packs badly, and tells the next reader that the number came from a decimal calculation somewhere upstream. The arithmetic is exact in either direction, so the only thing being optimised is how legible the number is to the next person who has to change it.