GiB in kB 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 Kilobyte sind 1.000 Byte, wenn ein Normungsgremium es definiert, und 1.024, wenn ein Betriebssystem es tut. Diese Seite rechnet mit 1.000; die Einheit für 1.024 heißt Kibibyte.

Der Faktor ist 1073741,824, und den trägt praktisch niemand mit sich herum. Auf 1070000 gerundet liegt er um 0,35 % daneben — bei kleinen Zahlen unsichtbar, bei etwa 1.000 GiB 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 GiB sind 1.024 der Einheit darunter, ein GB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 1073741,824 kB und 1000000 kB — 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.

/proc/meminfo gibt auf jedem Linux-Host seine Werte mit dem Zusatz „kB" aus, und jeder davon ist ein Kibibyte. Die Bezeichnung stammt aus einer Zeit lange vor den IEC-Vorsilben, und sie heute zu ändern würde jeden Parser, jeden Agenten und jedes Skript brechen, das die Datei seither liest. Die meistgelesene Speicherquelle auf der ganzen Plattform meldet also eine Einheit unter dem Namen einer anderen — dauerhaft.

Das wirkt sich aus, weil kaum noch etwas /proc/meminfo direkt liest. Exporter, Agenten und Container-Laufzeiten lesen die Datei, skalieren den Wert und reichen ihn ans Dashboard weiter, und jede dieser Schichten entscheidet für sich, ob der empfangene Wert dezimal oder binär gemeint war. Eine Speicherzahl auf einem Graphen hat meist schon eine falsch benannte Einheit durchlaufen, bevor überhaupt jemand hinschaut.

Monitoring-Anzeigen wählen für Speicher und Festplatte fast immer Gibibyte, weil die Zahlen bei dieser Skala lesbar bleiben. Womit sie verglichen werden, ist häufig viel kleiner und von einem Menschen geschrieben: ein Pro-Anfrage-Budget von 200 kB, eine durchschnittliche Objektgröße von 40 kB, eine Zahl aus dem Kapazitätsdokument eines anderen Teams. Von Hand geschriebene Zahlen sind fast ausnahmslos dezimal.

Der Vergleich überbrückt also eine Millionenlücke bei der Vorsilbe und eine Lücke von 7,37 Prozent zwischen den Systemen — und in der Regel geschieht das im Kopf, während gerade ein Vorfall läuft. Genau das ist der schlechteste Moment dafür, weshalb es sich lohnt, einmal umzurechnen, das Ergebnis mit Einheit im Runbook festzuhalten, und es nicht unter Zeitdruck jedes Mal neu herzuleiten.

Grafanas Einheitenliste enthält Byte in einer SI-Variante und Byte in einer IEC-Variante, wählbar pro Panel. Wird die erste gewählt, zeigt 8.589.934.592 Byte als 8,59 GB an; wird die zweite gewählt, als 8 GiB. Beide sind dieselbe Messung und beide korrekt beschriftet, aber die Beschriftung ist klein, der Unterschied beträgt 7,37 Prozent, und wer zwei Dashboards vergleicht, prüft selten zuerst die Panel-Einstellung.

Besonders anfällig ist ein Dashboard, das aus Panels verschiedener Autoren und Zeitpunkte zusammengesetzt wurde. Zeigt eines den Hostspeicher in GiB und das nächste ein Container-Limit in GB, wirken beide direkt vergleichbar. Liegen zwei Zahlen, die eigentlich übereinstimmen sollten, konstant um rund sieben Prozent auseinander, ist die Panel-Einheit der erste Verdacht — und ein einziger Klick klärt ihn.

Prometheus-Exporter und die meisten modernen Agenten melden rohe Bytezahlen. node_memory_MemAvailable_bytes ist eine Byte-Anzahl ohne jede Skalierung, und der Name sagt das auch. Das ist die richtige Bauweise: Die Metrik trägt die Messung, die Anzeige trägt die Darstellung, und eine Uneindeutigkeit kann erst dort entstehen, wo ein Mensch ein Format ausgewählt hat.

Das eröffnet auch den schnellsten Weg zur Klärung eines Widerspruchs. Weichen zwei Ansichten desselben Systems voneinander ab, hilft eine Abfrage der zugrunde liegenden Metrik und ein Vergleich der Bytezahlen — die können nicht in der falschen Einheit stehen. Fast jede Diskussion darüber, ob der Speicherverbrauch tatsächlich 7,4 Prozent höher ist als gemeldet, endet dort, in etwa dreißig Sekunden.

Ein Alarm, der „Speicher über 85 Prozent" auslöst, teilt eine Bytezahl durch eine andere, und die Einheiten kürzen sich heraus. Er lässt sich durch keine Anzeigekonvention brechen, übersteht die Größenänderung eines Hosts und braucht keinerlei Umrechnung. Deshalb ist der überwiegende Teil sinnvoller Alarmierung als Verhältnis formuliert, und deshalb sollte eine Seite über Einheitenumrechnung genau das auch sagen, statt es zu verschweigen.

Absolute Schwellen haben trotzdem ihren Platz: ein Limit, das exakt zur konfigurierten Container-Grenze passen muss, ein Festplattenwert, bei dem der freie Platz zählt statt des Anteils. Solche Werte gehören in der Alarmdefinition in Byte geschrieben und erst zur Anzeige formatiert. Eine Schwelle, die als 8 GB eingetragen wird, während das Limit als 8 GiB konfiguriert ist, liegt um 6,87 Prozent zu niedrig und löst bei jedem Durchlauf zu früh aus.

free meldet standardmäßig in Kibibyte und bietet -m, -g und -h für größere binäre Einheiten an. ps und top zeigen die residente Speichergröße in Kibibyte. vmstat rechnet in 1.024-Byte-Blöcken, slabtop zählt in Kibibyte. Zwischen ihnen decken diese Werkzeuge fast alles ab, was ein Administrator bei der Fehlersuche nach einem Speicherproblem betrachtet, und keines davon schreibt ein i.

Diese Konsequenz hilft zumindest: Auf einem Linux-Host ist eine kleine Speicherzahl ohne ausdrückliche Einheit fast immer Kibibyte, nicht Kilobyte, und Multiplizieren mit 1.024 führt zu Byte. Die Falle liegt nicht innerhalb der Plattform, sondern an ihren Rändern — wo eine Zahl aus einer Cloud-Konsole, einem Herstellerdokument oder einer Spezifikation in echten dezimalen Kilobyte ankommt und optisch genauso aussieht wie die übrigen.

Das Speicherlimit eines Containers und sein aktueller Verbrauch liegen beide im cgroup-Dateisystem als reine Byte-Ganzzahlen vor — memory.max und memory.current unter cgroup v2. Dort ist nichts skaliert, beschriftet oder gerundet. Jede Zahl, die ein Dashboard für einen Container anzeigt, wurde aus einer dieser Dateien gelesen und irgendwo weiter oben im Stapel formatiert — genau dort, wo eine Einheitenentscheidung getroffen wurde.

Das liefert einen eindeutigen Weg, jeden Streit über den Speicher eines Containers zu beenden. Die Dateien lesen, die Ganzzahlen vergleichen, und die Frage, ob ein Limit 4 GB oder 4 GiB sind, hört auf, Auslegungssache zu sein: 4.294.967.296 ist das eine, 4.000.000.000 das andere, und die Datei sagt, welches. Dasselbe Prinzip wie beim exakten Byte-Wert in den Dateieigenschaften — nur eine Ebene tiefer und bei einer Zahl, die darüber entscheidet, ob ein Prozess beendet wird.