GB in MiB umrechnen

Ein Gigabyte ist eine Milliarde Byte, im dezimalen Sinn, den Festplattenhersteller, Mobilfunktarife und Videogrößen verwenden.

Ein Mebibyte sind 1.024 Kibibyte, also 1.048.576 Byte. Linux-Werkzeuge und Speicherangaben meinen in aller Regel das, auch wenn „MB" dasteht.

Der Faktor ist 953,674316, und den trägt praktisch niemand mit sich herum. Auf 950 gerundet liegt er um 0,39 % daneben — bei kleinen Zahlen unsichtbar, bei etwa 1.000 GB wird daraus eine ganze Einheit.

Genau das ist die Zahl, die man vor dem Runden wissen will: nicht der Fehler selbst, sondern ab wann er aufhört, egal zu sein. Darunter ist der kurze Faktor der vernünftige; darüber nimm das Feld oben, das erst beim Ausgeben rundet.

Ein MiB sind 1.024 der Einheit darunter, ein MB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 0,001 GB und 0,001 GB — 4,9 % —, und der Abstand wächst mit jeder Stufe. Bei einem Foto ist er ein Rundungsfehler, bei einer Festplatte ein sichtbares Stück.

Darin besteht das Rätsel um den fehlenden Speicherplatz vollständig. Eine Platte, die als MB verkauft wird, enthält exakt das, was draufsteht; Windows teilt anschließend durch 1.024 statt durch 1.000, behält den dezimalen Namen bei und zeigt deshalb eine kleinere Zahl an. macOS rechnet seit Version 10.6 in den dezimalen Einheiten und zeigt die Zahl von der Verpackung — dieselbe Platte, zwei Rechner, zwei Größen, und verloren geht dabei nichts.

Ein Gigabyte sind eine Milliarde Byte, ein Mebibyte 1.048.576. Die Division ergibt 953,67431640625 — exakt, ohne Rundung, und eine Zahl, die niemand aus dem Kopf schätzt. Der Reflex ist, entweder mit 1.000 zu rechnen, was 4,9 Prozent zu viel ergibt, oder mit 1.024, was 7,4 Prozent zu viel ergibt — beides falsch, weil dieses Paar genau zwischen den beiden Einheitensystemen liegt.

Auf einem Grafana-Dashboard ist das eine leicht verschobene Linie. Bei einer Alarmschwelle ist es ein Alarm, der bei einem anderen Prozentsatz auslöst als geplant, und bei einer Kapazitätsplanung ist es der Unterschied zwischen ausreichend dimensioniert und im entscheidenden Moment sieben Prozent zu knapp.

Deutsche Cloud-Anbieter wie Hetzner verkaufen Arbeitsspeicher und Plattenplatz in dezimalen Gigabyte, so wie es auf der Bestellseite steht — ein Server mit „32 GB RAM“ hat 32.000.000.000 Byte Hauptspeicher zugesagt. Innerhalb der laufenden Instanz meldet der Kernel denselben Speicher aber binär, in Kibibyte oder Mebibyte, weil das die traditionelle Zähleinheit von Linux-Tools wie free und /proc/meminfo ist.

Wer aus der gebuchten GB-Zahl auf der Rechnung eine MiB-Zahl für eine interne Kapazitätsplanung ableiten will — etwa um zu prüfen, wie viel Arbeitsspeicher für Container-Limits übrig bleibt —, muss durch 953,674 statt durch 1.000 oder 1.024 rechnen, sonst weicht die geplante Reserve von der tatsächlich verfügbaren ab.

Alarmschwellen sind fast immer als Anteil an etwas gemeint: bei 80 Prozent der Festplatte warnen, bei 90 Prozent des Speicherlimits eskalieren. Diese Absicht bleibt nur erhalten, wenn der Anteil in der Einheit der ursprünglichen Zusage berechnet und erst am Ende umgerechnet wird. Achtzig Prozent eines Gigabyte sind 762,9 MiB, neunzig Prozent sind 858,3 MiB — beides Zahlen, die niemand freiwillig als Schwellenwert einträgt.

Eingetragen wird stattdessen meist 800 beziehungsweise 900, runde Zahlen, die aber nicht mehr die gemeinten Prozentsätze sind: 800 MiB sind 84 Prozent eines Gigabyte, 900 MiB sind 94 Prozent. Der Alarm funktioniert weiterhin, löst nur später aus, als es im Runbook steht, und der Unterschied fällt nicht auf, weil sowohl die Regel als auch die Dokumentation plausibel runde Zahlen enthalten.

Prometheus selbst bezieht keine Position: Die Konvention unter den meisten Exportern ist, rohe Byte-Werte mit dem Suffix _bytes zu speichern und die Einheit der Darstellungsschicht zu überlassen. Das verschiebt die Entscheidung ins Grafana-Panel, wo sie pro Feld getroffen wird, oft von wem auch immer das Dashboard gebaut hat, und selten dokumentiert an einer Stelle, die die Person liest, die später den Graphen ansieht.

Zwei Panels auf demselben Dashboard können dieselbe Zeitreihe um sieben Prozent auseinander anzeigen und beide korrekt konfiguriert sein — eine Abfrage liefert Byte, ein Panel formatiert im dezimalen, eines im binären Sinn, und die Achsenbeschriftung sagt GB oder GiB oder, im schlechtesten Fall, beide sagen GB. Bei einem Vergleich mit einer Zahl aus einer anderen Quelle lohnt zuerst der Blick auf die Feldeinstellung, nicht auf die Achsenbeschriftung.

In Kubernetes-Manifesten, die auf deutschen Clustern ebenso laufen wie überall sonst, ist der Unterschied explizit im Suffix codiert: Mi und Gi sind binäre Größen, M und G dezimale. Ein Limit von 1G sind 1.000.000.000 Byte, eines von 1Gi sind 1.073.741.824 — beide gültig, beide werden ohne Warnung angewendet, und sie unterscheiden sich um 7,4 Prozent.

Die Falle entsteht in einer Kette, in der sich die Einheit an jedem Glied ändert: die gebuchte Kapazität in dezimalen GB, der Node in GiB beschrieben, ein Limit in Mi gesetzt, ein Dashboard, das anzeigt, wofür es konfiguriert wurde. Jede einzelne Umrechnung in dieser Kette ist machbar; der Fehler entsteht, wenn drei davon aus dem Kopf gemacht werden. Besser einmal an der Stelle des Vergleichs alles in Byte umrechnen und die handlichen Einheiten nur für die Anzeige verwenden.