Convert GiB to kB

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 kilobyte is 1,000 bytes when a standards body defines it and 1,024 when an operating system does. This page uses 1,000; the kibibyte is the unit that means 1,024.

The factor is 1073741.824, and almost nobody carries that around. Rounded to 1070000 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 1073741.824 kB and 1000000 kB — 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 1000000 kB where the box said 1073741.824. 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.

/proc/meminfo on every Linux host prints its values with the suffix "kB", and every one of them is a kibibyte. The label predates the IEC names by many years, and changing it now would break every parser, agent and script that has read the file since. So the most-consulted source of memory figures on the platform reports in one unit and names another, permanently.

That matters because almost nothing reads /proc/meminfo directly any more. Exporters, agents and container runtimes read it, scale it, and hand it to a dashboard, and each layer decides for itself whether the number it received was decimal or binary. A memory figure on a graph has usually passed through a mislabelled unit before anybody looks at it, and the error, where there is one, was introduced upstream of the panel.

Monitoring displays settle on gibibytes for memory and disk because that is the scale at which the numbers are readable. The things those numbers get compared against are frequently much smaller and written by a person: a per-request memory budget of 200 kB, an average object size of 40 kB, a cache entry cost, a figure from another team’s capacity document. Human-written figures are decimal almost without exception.

So the comparison crosses both a prefix gap of a million and a unit-system gap of 7.37 per cent, and it usually crosses them in somebody’s head during an incident. That is the worst available time to be doing it, which is the argument for converting once, writing the result down with its unit, and putting it in the runbook rather than deriving it again under pressure.

Grafana’s unit list contains bytes in an SI flavour and bytes in an IEC one, chosen per panel. Pick the first and 8,589,934,592 bytes renders as 8.59 GB; pick the second and it renders as 8 GiB. Both are the same measurement and both are labelled honestly, but the label is small, the difference is 7.37 per cent, and nobody comparing two dashboards checks the panel configuration first.

The place this bites is a dashboard assembled from panels built by different people at different times. One shows a host’s memory in GiB and the next shows a container’s limit in GB, and the two sit side by side looking directly comparable. If two figures that should match are consistently about seven per cent apart, the panel unit is the first thing to inspect and it takes one click.

Prometheus exporters, and most modern agents, report raw byte counts. node_memory_MemAvailable_bytes is a number of bytes with no scale attached, and the name says so. That is the correct design: the metric carries the measurement and the display carries the presentation, so the ambiguity can only be introduced where a human chose a format.

It also means the resolution to any disagreement is available. When two views of the same system differ, query the underlying metric and compare byte counts, which cannot be in the wrong unit. Almost every argument about whether memory usage is 7.4 per cent higher than reported ends there, in about thirty seconds, without anybody having to be right in advance.

An alert written as "memory above 85 per cent" divides one byte count by another, and the units cancel. It cannot be broken by a display convention, it survives the host being resized, and it needs no conversion at all. That is why the great majority of useful alerting is expressed as a ratio, and why a page about unit conversion should say so rather than pretending otherwise.

Absolute thresholds still have their place: a limit that must match a container’s configured memory, a disk figure where the free space matters rather than the proportion, a quota agreed contractually. Those should be written in bytes in the alert definition and formatted for display only. A threshold typed as 8 GB against a limit configured as 8 GiB is under-set by 6.87 per cent and will fire early, every time, for the life of the rule.

free reports in kibibytes by default and offers -m, -g and -h for larger binary units. ps and top show resident set size in kibibytes. vmstat uses 1,024-byte blocks. slabtop counts in kibibytes. Between them these cover most of what an engineer looks at while diagnosing a memory problem, and none of them writes an i.

The consistency is at least helpful: on a Linux host, a small memory figure without an explicit unit is almost certainly kibibytes rather than kilobytes, and multiplying by 1,024 gets you to bytes. The trap is not within the platform but at its edges, where a figure from a cloud console, a vendor document or a specification arrives in genuine decimal kilobytes and looks exactly like the others.

A number that leaves the monitoring stack loses the context that made it interpretable. In a ticket, a report or a post-incident write-up, "the process was using 1.4 GB" will be read by different people as 1.4 GiB and as 1.4 GB, and those differ by 100 megabytes at that scale — enough to matter in an argument about whether a limit was exceeded.

Writing the byte count alongside is the cheapest possible protection, and at this scale it is a single extra clause: "1.4 GiB, which is 1,503,239 kB". It removes the conversion, the convention and the argument in one line, and it is the same discipline that makes any measurement in an incident record worth re-reading a year later.

A container's memory limit and its current usage both live in the cgroup filesystem as plain byte integers — memory.max and memory.current on cgroup v2. Nothing there is scaled, labelled or rounded. Every figure a dashboard shows for a container has been read from one of those files and formatted by something further up the stack, which is the layer where a unit choice was made.

That gives a decisive way to settle any disagreement about a container's memory. Read the files, compare the integers, and the question of whether a limit is 4 GB or 4 GiB stops being a matter of interpretation: 4,294,967,296 is one and 4,000,000,000 is the other, and the file says which. It is the same principle as reading the exact byte count in a file properties dialog, applied one layer down and to a number that decides whether a process is terminated.