GiB in B umrechnen

Ein Gibibyte sind 1.073.741.824 Byte, rund 7 % mehr als ein Gigabyte. Windows misst in Gibibyte, schreibt aber „GB" daran — darin besteht das ganze Rätsel des verschwundenen Speicherplatzes.

Ein Byte sind acht Bit, was nicht immer feststand — frühe Rechner nutzten sechs, sieben oder neun. Acht setzte sich durch, weil damit ein Schriftzeichen hineinpasst und die Zahl sich sauber halbieren lässt.

In dieser Richtung wird multipliziert, und zwar mit einer ganzen Zahl: ein Gibibyte sind 1.073.741.824 Byte, exakt. 1.073.741.824 ist die Definition und keine Messung, die knapp danebenlag.

Damit ist es eine der wenigen Umrechnungen, die sich im Kopf lohnen, und das Ergebnis lässt sich prüfen: rechne zurück, und du musst exakt auf der Ausgangszahl landen, ohne Rest, den man wegerklären müsste.

Ein GiB sind 1.024 der Einheit darunter, ein GB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 1073741824 B und 1000000000 B — 7,4 % —, 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 GB 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.

Etliche Einstellungen nehmen eine reine Ganzzahl und keinerlei Einheit, und die Dokumentation daneben sagt schlicht „Byte". Eine Objektgröße im Storage-Backend, ein Anfrage-Limit in einem Java-Framework, eine Pufferzahl in der Datenbankkonfiguration: Für jedes davon ist der Wert eines Gibibyte exakt 1.073.741.824. Multiplizieren reicht, weil beide Einheiten feste Zweier- beziehungsweise Zehnerpotenzen sind und nichts gerundet werden muss.

Warum die binäre Einheit statt einer runden Dezimalzahl steht, liegt am Unterbau: Speicherseiten, Blockgrößen und Adressräume sind auf Zweierpotenzen gebaut, und ein Limit von 1.000.000.000 Byte sitzt unbequem zwischen zwei davon. 1.073.741.824 fügt sich in den Allokator darunter, weshalb jedes Werkzeug, das ein Suffix erlaubt, es genau so auflöst.

Die Konvention in der Betriebswerkzeugkiste ist, dass ein nacktes k, m oder g für 1.024, 1.048.576 oder 1.073.741.824 steht. Die Heap-Flags der Java Virtual Machine funktionieren so, also reserviert -Xmx4g 4.294.967.296 Byte. Die Speicher- und Storage-Limits von Docker funktionieren so, ebenso die Ressourcen-Direktiven von systemd. Keines davon kennzeichnet sich als binär — der Buchstabe sieht dezimal aus und rechnet binär.

Der Unterschied zu einem runden Gigabyte beträgt 7,4 Prozent, und der fällt genau dort auf, wo es wehtut: bei einem Java-Prozess in einem Container mit fester Speichergrenze. Wer den Heap gegen die dezimale Annahme dimensioniert, reserviert am Ende weniger, als das Limit hergibt, und der Prozess läuft mit ungenutzter Reserve statt mit knapper Kante.

Ressourcenangaben in Kubernetes tragen den Unterschied im Suffix: Gi ist binär, also ist 1Gi exakt 1.073.741.824 Byte; G ohne i ist dezimal, also ist 1G exakt 1.000.000.000. Dasselbe gilt bei jeder Skalenstufe — Ki gegen k, Mi gegen M, Ti gegen T — und das Manifest meint präzise das, was dasteht, ohne dass ein werkzeugspezifisches Wörterbuch nötig wäre.

Diese Klarheit hat eine scharfe Kante. Ein Speicherlimit, das 4G statt 4Gi schreibt, ist um 294.967.296 Byte kleiner — rund sieben Prozent, unsichtbar im Code-Review. Läuft ein Pod nah an seiner Grenze, entscheidet genau dieser fehlende Buchstabe darüber, ob er in einem lastintensiven Moment durchhält oder wegen Speicherüberschreitung beendet wird.

Die GNU-Coreutils gehen noch einen Schritt weiter und akzeptieren beide Schreibweisen, mit einer Regel, die leicht zu merken und leicht zu vergessen ist: Ein einzelner Buchstabe ist binär, eine zweibuchstabige Form, die auf B endet, ist dezimal. dd bs=1G kopiert in Blöcken von 1.073.741.824 Byte, dd bs=1GB in Blöcken von 1.000.000.000. In der Shell-History sehen die beiden Befehle fast identisch aus und unterscheiden sich bei jedem einzelnen Block um sieben Prozent.

Für einen Administrator, der eine Festplatte klont oder ein Backup zieht, ist das mehr als Kosmetik: Bei einem Transfer von mehreren hundert Gigabyte summiert sich der falsche Suffix zu einer spürbar anderen Blockanzahl, ohne dass dd selbst irgendeine Warnung ausgibt. Das Werkzeug tut exakt, was verlangt wurde — nur eben mit dem Buchstaben, der tatsächlich dastand.

Ein paar Byte-Zahlen tauchen in Fehlermeldungen und Limitfeldern immer wieder auf, und sie zu kennen erspart eine Umrechnung: 1.048.576 ist ein Mebibyte, 1.073.741.824 ein Gibibyte, 2.147.483.648 sind zwei davon, und 4.294.967.296 ist 2³² — die exakte Größe eines 32-Bit-Adressraums. Einen davon zu kennen heißt, in einer Log-Zeile sofort zu sehen, welche Grenze gerade erreicht wurde.

Einen weniger als diese Zahlen zählt genauso: 2.147.483.647 ist der größte vorzeichenbehaftete 32-Bit-Wert, und jede Byte-Zahl, die in einem solchen Feld steckt, endet dort. Eine Datei, die bei 1,9 GiB noch hochlädt und bei 2,1 abbricht, trifft in der Regel genau diese Grenze — und keine noch so großzügige Konfiguration ändert daran etwas.

Eine Konfigurationszeile mit dem Wert 8589934592 sagt einem Reviewer nichts über die Absicht dahinter. Derselbe Wert als 8 1024 1024 * 1024 geschrieben, wo das Format einen Ausdruck erlaubt, oder mit einem Kommentar „acht Gibibyte" versehen, lässt sich auf einen Blick prüfen. Jede große Byte-Konstante in einem Repository ist eine Zahl, die irgendwann jemand nachvollziehen muss, und nur die, die ihre eigene Herleitung trägt, übersteht einen Umbau unbeschadet.

Wo die Syntax ein Suffix zulässt, ist es dem ausgeschriebenen Wert vorzuziehen: Fast jeder Tippfehler in 1Gi ist ein Syntaxfehler, und der einzige, der es nicht ist — das fehlende i — kostet sieben Prozent; ein Tippfehler in 1073741824 ergibt eine lauffähige Konfiguration mit einem Limit, das zehnmal zu groß oder zu klein ist. Diese Schieflage ist das ganze Argument für Suffixe, und sie erklärt, warum Werkzeuge, die sie einmal eingeführt haben, kaum wieder davon abrücken.

Die Reihe setzt sich in Schritten von 1.024 fort: Ein Tebibyte ist 2⁴⁰, also 1.099.511.627.776 Byte, ein Pebibyte 2⁵⁰, also 1.125.899.906.842.624. Beide tauchen eher in Limits als in Messwerten auf — maximale Objektgrößen, maximale Dateigrößen, Adressraumgrenzen —, weil das die Stellen sind, an denen jemand eine Zweierpotenz festlegen und niederschreiben musste.

Die Grenze, die in der Praxis am meisten zählt, liegt weit über allen dreien: Eine vorzeichenlose 64-Bit-Byte-Zahl reicht bis 16 EiB, was kein heutiges System auch nur annähernd erreicht — Byte-Zahlen laufen in moderner Software also nicht über. Was stattdessen passiert, ist ein Genauigkeitsverlust, sobald die Zahl eine Schicht durchläuft, die Werte als Gleitkommazahl speichert, und das geschieht bei etwa 8 PiB — weit unter der Typgrenze und weit über allem, was ein einzelnes Konfigurationsfeld je enthalten wird.