B in MiB umrechnen

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.

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

In dieser Richtung wird geteilt, und zwar durch eine ganze Zahl: 1.048.576 davon passen restlos in ein Mebibyte. Unangenehm ist daran nur, dass die Ergebnisse als Brüche herauskommen — ein Drittel, ein Zwölftel — statt als die runden Zahlen, die die Gegenrichtung liefert.

Verloren geht dabei trotzdem nichts, denn die Division ist exakt. Wenn dein Ergebnis als Dezimalzahl nicht stillhalten will — 0,0833… und Verwandte —, dann ist das der Bruch, der durchscheint, und kein Fehler, der sich einschleicht.

Ein MiB sind 1.024 der Einheit darunter, ein MB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 1048576 B und 1000000 B — 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.

Die Byte-Zahl ist der verlässliche Wert in diesem Zusammenhang. Sie kommt aus einem Dateisystemaufruf oder einem Content-Length-Header, hat keine Einheiten-Mehrdeutigkeit, und ist das, wogegen die Software am Ende tatsächlich vergleicht. Der MiB-Wert ist eine für Menschen gedachte Vereinfachung obendrauf, und jedes Problem in dieser Richtung entsteht dadurch, diese Vereinfachung als Quelle der Wahrheit zu behandeln.

Die Reihenfolge, die die Byte-Zahl maßgeblich lässt: durch 1.048.576 teilen, entscheiden, worauf gerundet wird, und dann zurückmultiplizieren, um zu prüfen, ob das geschriebene Limit die gemessene Datei noch zulässt. Dieser letzte Schritt dauert Sekunden und fängt genau die Fehlerklasse ab, für die diese Seite existiert — ein Limit ist nicht richtig, wenn es richtig aussieht, sondern wenn die Datei es besteht.

Eine Datei mit 10.486.000 Byte sind 10,0002 MiB. Als Upload-Limit "10m" eingetragen ist sie jetzt größer als das Limit und wird abgelehnt — mit einer Fehlermeldung, die behauptet, die Datei sei zu groß für ein Limit, das der Betreiber für exakt ihre Größe hielt. Abrunden ist die instinktive Gewohnheit, und für eine Obergrenze ist sie immer die falsche: Die Grenze muss mindestens so groß sein wie das größte, was sie zulassen soll.

Umgekehrt liegt der Fall bei einer Reservierung: Speicherplatz für einen Cache, einen Log-Puffer oder eine vorreservierte Datei muss abgerundet werden, weil Aufrunden eine Kapazität verspricht, die nicht vorhanden ist, und der Fehlbetrag später unter Last als Schreibfehler auftritt. Eine Frage entscheidet jedes Mal die Richtung: Wäre bei einem Fehler von einem Byte lieber etwas zu viel oder etwas zu wenig vorhanden?

Kubernetes ist unter den gängigen deutschen Container-Plattformen dasjenige, das am wenigsten rät: Mi, Gi und Ti sind die binären Mengen, M, G und T die dezimalen, beide sind in einem Manifest gültig, und ein Speicherlimit von 512M ist 4,6 Prozent kleiner als eines mit 512Mi. Nichts warnt davor — das Manifest wird angewendet, der Pod startet, und das Limit sitzt nicht dort, wo es gedacht war.

nginx behandelt seine Konfiguration anders und weniger deutlich: client_max_body_size 10m meint 10.485.760 Byte, weil nginx k und m durchgängig als 1.024 beziehungsweise 1.048.576 liest. Wer aus einem deutschen Hosting-Kontext gewohnt ist, dass MB dezimal gemeint ist, überträgt diese Annahme leicht auf ein Feld, das binär rechnet, und verschenkt dabei fast fünf Prozent Spielraum oder erlaubt fast fünf Prozent zu viel.

Ein Mebibyte ist 2 hoch 20, und deshalb taucht es als natürliche Größe für alles auf, was ein Kernel zuteilt. Speicherseiten sind 4 KiB groß, Huge Pages üblicherweise 2 MiB, und ein Puffer in Zweierpotenz-Größe fügt sich ohne Rest in beide ein. 1.000.000 Byte für denselben Puffer zu wählen ist nicht falsch, aber eine Zahl, die die darunterliegende Speicherverwaltung ohnehin aufrunden muss — die Ausrichtung wird dann auf einer tieferen Ebene zurückgekauft oder mit einer angebrochenen Seite bezahlt.

Die praktische Folge: Wenn Blockgröße, Part-Größe und Limit alle Vielfache derselben Zweierpotenz sind, geht jede Division glatt auf und keine Stufe hinterlässt einen Rest. Sobald eine dezimale Zahl in diese Kette eingeführt wird, erzeugt jede darunterliegende Stufe Reste — eine kleine Ineffizienz und eine größere Quelle für Off-by-one-Verwirrung.

Der teuerste Fehler auf dieser Seite ist nicht der Unterschied von 4,9 Prozent zwischen MB und MiB, sondern der Faktor acht zwischen Byte und Bit. Datei- und Speichergrößen werden in Byte gezählt, Durchsatz wird in Bit pro Sekunde angegeben — ein deutscher 100-Mbit/s-Anschluss liefert bestenfalls 12,5 MB/s, und ein 500-MiB-Download darüber dauert rund vierzig statt fünf Sekunden.

Die Konvention, die die beiden unterscheidet, ist ein großes B für Byte und ein kleines b für Bit — verbreitet genug, um sich darauf zu verlassen, und häufig genug verletzt, um sie zu prüfen. Wirkt eine Zahl acht Mal zu groß oder zu klein, ist das der erste Verdacht, noch vor der Frage, welches Tausend gemeint war — besonders bei einer Zahl, die aus einem Netzwerkdiagramm oder einem Datenblatt eines Providers stammt, wo Bit die Hausgröße ist.