TB in MiB umrechnen

Ein Terabyte ist eine Billion Byte. Eine als 1 TB verkaufte Platte hat genau das — der scheinbar fehlende Platz ist eine Meinungsverschiedenheit über Einheiten, kein Mangel.

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 953674,316406, und den trägt praktisch niemand mit sich herum. Auf 950000 gerundet liegt er um 0,39 % daneben — bei kleinen Zahlen unsichtbar, bei etwa 1.000 TB 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 TB und 0 TB — 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 deutscher Hosting-Anbieter verkauft Speicherplatz dezimal — ein Terabyte sind eine Billion Byte, so steht es im Vertrag und auf der Rechnung. Alles, was darunter mit dem Speicher arbeitet, denkt binär: LVM-Extents, Dateisystemblöcke, die Chunk-Größe eines Objektspeichers. Jede dieser Größen ist eine Zweierpotenz, und jede Division eines Terabyte-Vertrags durch eine dieser Größen lässt einen Rest übrig, der irgendwo verrechnet werden muss.

Die Umrechnung selbst ist eine einzige Division: Terabyte mal 1.000.000.000.000, geteilt durch 1.048.576, ergibt 953.674,316406 MiB je Terabyte — mehr Nachkommastellen zeigt der Rechner oben nicht an, weil er jedes Ergebnis auf zwölf signifikante Stellen rundet. Das Ergebnis liegt immer rund 4,9 Prozent unter dem, was eine naive Division durch eine Million vermuten lässt — wer diesen Schritt überspringt, plant ein Volumen, das um genau diesen Betrag zu knapp bemessen ist.

Hetzner Object Storage, IONOS S3 Object Storage und vergleichbare deutsche Angebote folgen der S3-Konvention und begrenzen Uploads auf maximal 10.000 Teile. Ein Terabyte großes Objekt braucht deshalb Teile von mindestens 100.000.000 Byte, also 95,37 MiB, sonst lässt sich der Upload nicht abschließen. Ein Fünf-Terabyte-Objekt braucht nach derselben Rechnung mindestens 476,84 MiB pro Teil.

In der Praxis wird die Teilgröße auf die nächste Zweierpotenz aufgerundet. 128 MiB deckt ein Terabyte in 7.451 Teilen ab und lässt bequem Luft bis knapp 1,34 Terabyte, bevor das Limit erneut erreicht wird. Eine Teilgröße von 100 MB würde rechnerisch funktionieren, aber an keiner darunterliegenden Struktur ausgerichtet sein — deshalb setzt sich die binäre Zahl in der Praxis durch.

Ein Terabyte sind 7.450,58 Blöcke zu 128 MiB: 7.450 volle und ein Rest von 74,32 MiB. Ein System, das nur ganze Blöcke vergibt, reserviert 7.451, wobei der letzte gut zwei Fünftel leer bleibt — ein Rundungsverlust von rund 54 MiB gegenüber einem Terabyte, also 0,005 Prozent, keine Größe, über die man bei einer einzelnen großen Datei nachdenken muss.

Dieselbe Rechnung am anderen Ende der Dateigrößenverteilung wird spürbar. Eine Million Dateien à 2 MiB in einer Blockgröße von 128 MiB belegen je eine volle Blockeinheit und verbrauchen 122 TiB Kapazität für 1,9 TiB tatsächlichen Inhalt. Die Blockgröße richtet sich nach der Arbeitslast, nicht nach der Kapazität, und erst die Umrechnung zeigt, was eine bestimmte Wahl tatsächlich kostet.

Ein Volume-Manager vergibt Speicher in Extents, üblicherweise 4 MiB, sodass ein Terabyte logisches Volumen 238.418,58 Extents ergibt und auf eine ganze Zahl davon aufgerundet wird. Wer auf einem Hetzner- oder IONOS-Root-Server ein LVM-Setup mit mehreren logischen Volumes anlegt, trifft diese Aufteilung bei jeder Größenangabe — und ein gestreiftes Layout fügt eine zweite Ausrichtung hinzu: Eine Streifenbreite, die ein Vielfaches der Extent-Größe ist, hält jeden Streifen auf einer Grenze.

Nichts davon zeigt sich in der Kapazitätsangabe des Vertrags, und alles folgt aus der Umrechnung. Die dezimale Größe in Mebibyte und dann in die jeweilige Zuteilungseinheit umzurechnen, zeigt, ob die gewählte Geometrie glatt aufgeht oder auf jeder Ebene einen Teilblock übrig lässt. Wo sie nicht glatt aufgeht, ist die übliche Lösung, das Volumen gleich in binären Einheiten zu bemessen und die dezimale Zahl das Ergebnis sein zu lassen.

Weil 1.000.000.000.000 und 1.048.576 nur Zweierfaktoren gemeinsam haben — die dezimale Zahl zwölf davon, die binäre zwanzig — geht ein Terabyte nie ohne Rest in Mebibyte auf und wird es auch nie tun. Jede Kapazität, die ohne Rest in binäre Einheiten aufgeht, wurde von Anfang an binär angegeben, und das ist ein nützlicher Hinweis, wenn eine fremde Speicherangabe auf dem Tisch liegt.

Deshalb zeigen Speichersysteme ihre Größen oft binär an, selbst wenn die zugrunde liegende Hardware dezimal verkauft wurde — sie wählen die Darstellung, in der ihre eigene Rechnung exakt aufgeht. Diese Umrechnung existiert vor allem für den Moment, in dem eine dezimale Vertragsangabe von außen mit der binären Rechnung im System abgeglichen werden muss.

Wer mehrere Root-Server bei einem deutschen Anbieter betreibt und deren Snapshots zentral in einem Objektspeicher-Bucket ablegt, trifft die Chunk-Rechnung im Betrieb regelmäßig: Jeder Snapshot wird beim Hochladen in Teile derselben festen Größe zerlegt, unabhängig davon, wie groß das Ursprungsvolumen war. Bei mehreren hundert Servern mit unterschiedlichen Plattengrößen ist die Teilgröße deshalb sinnvollerweise gegen den größten vorkommenden Server bemessen, nicht gegen den Durchschnitt — sonst reißt gerade der größte Snapshot das Zehntausend-Teile-Limit als Erster.

Das Gegenstück zur Chunk-Rechnung ist die Kontrolle über die tatsächlich hochgeladene Menge: Ein inkrementeller Snapshot überträgt im Idealfall nur die veränderten Blöcke, aber wird er als vollständig neues Objekt hochgeladen statt als Delta, zählt für die Teileberechnung die volle Größe erneut. Diese Unterscheidung zu kennen entscheidet, ob die 128-MiB-Teilgröße für Jahre ausreicht oder bei jedem neu hinzukommenden Server neu geprüft werden muss.

Die Teilgröße bringt zwei Kosten gegeneinander in Stellung. Kleine Teile bedeuten eine hohe Anzahl, mehr Anfragen, mehr Verwaltungsaufwand und ein früher erreichtes Teilelimit; große Teile bedeuten weniger Anfragen und einen größeren Verlust bei einem Fehlschlag, weil ein fehlgeschlagenes Teil komplett neu übertragen wird. Bei 128 MiB kostet eine abgebrochene Verbindung bis zu 134 Millionen Byte erneute Übertragung — auf einer unzuverlässigen Leitung kann das den Aufwand übersteigen, den die große Teilgröße eigentlich einsparen sollte.

Die Umrechnung der Gesamtkapazität macht diese Abwägung sichtbar. Ein Terabyte sind bei 16 MiB pro Teil 59.605 Teile, bei 128 MiB sind es 7.451, bei 512 MiB sind es 1.863. Die mittlere Größe ist der übliche Kompromiss nicht wegen einer besonderen Eigenschaft der Zahl, sondern weil sie zwischen einem Teilelimit von 10.000 und einer Wiederholungskosten liegt, die sich in Minuten bemisst.