GiB in MB 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 Megabyte ist eine Million Byte. Speicherhersteller haben immer dezimal gerechnet — deshalb wirken ihre Angaben größer als das, was der Rechner anzeigt.

Der Faktor ist 1073,741824, und den trägt praktisch niemand mit sich herum. Auf 1070 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 1073,7418 MB und 1000 MB — 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.

Ein Speicherbaustein wird über Adressleitungen ausgewählt, und n Leitungen erreichen genau 2 hoch n Speicherplätze — zehn Leitungen ergeben 1.024, zwanzig ergeben 1.048.576, dreißig ergeben 1.073.741.824. Es gibt keine Verdrahtung, die eine runde Dezimalzahl an Speicherplätzen ergibt, also ist die Kapazität von Arbeitsspeicher durch die Bauweise eine Zweierpotenz, nicht durch eine Marketingentscheidung.

Deshalb enthält ein als „32 GB" verkauftes Modul 34.359.738.368 Byte, also 32 GiB, und niemand widerspricht dem. Das ist dieselbe dezimale Beschriftung einer binären Größe, die bei Festplatten Streit auslöst — nur dass sie hier niemanden stört, weil die Alternative, Speicherriegel mit exakt 32.000.000.000 Byte zu bauen, physikalisch nicht existiert.

Die Rechnung ist eine Multiplikation mit 1.073,741824: 8 GiB sind 8.589,93 MB, 16 GiB sind 17.179,87 MB, 64 GiB sind 68.719,48 MB. Diese Zahlen sind korrekt dezimal — und fast nie das, was ein Zuweisungsfeld will, denn ein Feld, das nach Speicher in „MB" fragt, meint fast immer Mebibyte und erwartet 8.192, 16.384 oder 65.536.

Proxmox‘ eigene Oberfläche ist genau dieser Fall: Der Speicher-Slider einer VM ist in Mebibyte kalibriert, auch wenn daneben „MiB" oder schlicht „MB" steht, je nach Version. Wer aus einem gebuchten Hetzner-Server mit „64 GB RAM" (also 64 GiB) die dezimal umgerechnete Zahl 68.719 in dieses Feld einträgt, weist der VM fast 4,9 Prozent zu viel zu und lässt weniger für den Host, den Cache und die übrigen Gäste übrig, als geplant war.

Eine runde binäre Zahl zuweisen und nachsehen, was der Gast meldet, beantwortet die Frage schneller als jede Dokumentation. 4.096 in das Feld eingetragen, VM gestartet, free -h im Gast ausgeführt: Zeigt der Gast exakt 4 GiB, war das Feld Mebibyte; zeigt er 3,81 GiB, war es dezimales Megabyte. Der Test dauert eine Minute und die Antwort gilt danach dauerhaft für diese Plattform.

Das lohnt sich, weil Dokumentation an dieser Stelle häufig von jemandem geschrieben wurde, der die Frage selbst nie gestellt hat. Das beobachtete Verhalten ist verlässlicher als die Beschriftung, und dasselbe Prinzip gilt für jede andere Virtualisierungsoberfläche, bei der ein Speicherfeld ohne erkennbare Einheit dasteht.

Die Kette von der GiB-Zahl des Hosts bis zur Zuteilung eines einzelnen Dienstes durchläuft meist drei Einheiten und mindestens eine Subtraktion. Der Host meldet GiB. Ein Teil muss für den Host selbst, den Seiten-Cache und Proxmox‘ eigene Prozesse übrig bleiben. Der Rest geht in ein MB- oder MiB-Feld der VM, und innerhalb der VM wird daraus wiederum ein Heap für eine Datenbank oder eine JVM mit ihren eigenen Aufschlägen.

Zuverlässig ist, jeden Schritt in Byte zu rechnen und erst am Ende in die jeweils verlangte Einheit umzuwandeln. Wer zwischendurch mit gemischten Einheiten rechnet, subtrahiert eine dezimale Zahl von einer binären, und das Ergebnis ist weder das eine noch das andere — eine Zuweisung, die um ein paar Prozent daneben liegt, ohne dass irgendwo dokumentiert ist, in welche Richtung.

Proxmox erlaubt es wie jeder Hypervisor, mehr Speicher an VMs zu versprechen, als der Host physisch besitzt, in der plausiblen Annahme, dass nicht alle Gäste gleichzeitig ihr Maximum brauchen. Eine Zuweisung, die stillschweigend fünf Prozent zu klein ist, scheitert deshalb nicht beim Anlegen der VM und nicht beim Booten — sie scheitert erst unter genau der Last, für die die Größe eigentlich gedacht war.

Wenn es dann passiert, zeigt das Symptom in die falsche Richtung. Ein Gast, der swapt, ein Java-Heap, der mehr Zeit mit Garbage Collection verbringt, ein Datenbank-Cache mit schlechterer Trefferquote als erwartet — alles sieht nach einem Tuning-Problem aus, während die Zahl in der Proxmox-Konfiguration korrekt aussieht, weil sie die Zahl ist, die jemand eintragen wollte. Nachzusehen, was der Gast tatsächlich erhalten hat, ist der Schritt, der die eigentliche Ursache findet.

Nichts verbietet, einer VM 4.000 MB zuzuweisen, und es funktioniert. Es teilt sich nur nicht glatt durch die Seitengröße, Huge Pages und die meisten darunterliegenden Strukturen, sodass jede Ebene leicht aufrundet und die eingetragene Zahl nie ganz die wirksame ist. Eine Zuweisung von 4.096 MiB läuft dagegen unverändert durch alle Ebenen, was jede spätere Messung leichter nachvollziehbar macht.

Dazu kommt ein Dokumentationsvorteil, der auf einem Proxmox-Cluster mit vielen VMs schnell zählt: Eine Konfiguration voller Zweierpotenzen ist selbsterklärend — wer 8.192 sieht, weiß ohne Rechnung, dass es 8 GiB sind, während 8.590 nachgeschlagen und leicht zu etwas Plausiblem verschrieben werden muss. Eine Übersicht, in der jede VM eine Zweierpotenz zugewiesen bekommt, lässt sich zudem im Kopf gegen den installierten Host-Speicher aufsummieren, ohne dass irgendetwas umgerechnet werden müsste.