TiB in GiB umrechnen

Ein Tebibyte sind 1.024 Gibibyte. Der Abstand zum Terabyte wächst mit jeder Stufe: 2,4 % bei Kilo, 4,9 % bei Mega, 7,4 % bei Giga, 10 % bei Tera.

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.

In dieser Richtung wird multipliziert, und zwar mit einer ganzen Zahl: ein Tebibyte sind 1.024 Gibibyte, exakt. 1.024 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 TiB sind 1.024 der Einheit darunter, ein TB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 1024 GiB und 931,3226 GiB — 10 % —, 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 TB 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.

Fast jede Schnittstelle, die Speicherplatz anfordert, verlangt eine Gibibyte-Angabe. Blockvolumes bei europäischen Managed-Kubernetes-Angeboten wie Open Telekom Cloud, IONOS Cloud oder StackIT werden in ganzen GiB bereitgestellt. Eine Kubernetes Persistent Volume Claim wird als storage: 100Gi geschrieben. VM-Platten und LVM-Volumes liegen auf derselben Skala. Der Pool dahinter — ein Array, ein SAN, ein ZFS-Pool — wird in Tebibyte beschrieben, weil das die Einheit ist, in der die Beschaffung selbst stattfindet.

Die Umrechnung ist also eigentlich eine Division in eine Stückzahl. Ein 10-TiB-Pool sind 10.240 GiB, also 102 Volumes zu 100 GiB, oder 20 zu 512, oder 5 zu 2.048. Diese Stückzahl vor der ersten Bestellung zu kennen macht die Lebensdauer des Pools planbar — und genau dieser Schritt entfällt, wenn Volumes einzeln, je nach eingehender Anfrage, bereitgestellt werden.

Ein dünn bereitgestelltes Volume meldet dem Nutzer seine volle Größe und verbraucht nur die tatsächlich beschriebenen Blöcke. Deshalb können hundert Volumes zu 100 GiB — 10.000 GiB an Zusagen — auf einem 2-TiB-Pool liegen und dabei nur 800 GiB verbrauchen, und das ist keine Trickserei, sondern eine reale Effizienz: Die meisten Volumes sind größtenteils leer, und Platz für Daten zu reservieren, die nie entstehen werden, wäre Verschwendung.

Das Risiko besteht darin, dass die Zusagen real sind und der Pool es nicht ist. Nähert sich die tatsächliche Nutzung dem Pool an, beginnen Schreibvorgänge auf Volumes zu scheitern, deren eigene Anzeige noch viel freien Platz meldet — und das Gast-Dateisystem hat keine Möglichkeit, das zu interpretieren, weil ein Schreibfehler auf einem vermeintlich gesunden Gerät eher zu Dateisystem-Beschädigung als zu einer sauberen Fehlermeldung führt. Ein Thin Pool braucht deshalb eine Überwachung, die auf die Auslastung des Pools schaut, nicht auf die eines einzelnen Volumes.

Ein LVM-Thin-Pool führt ein Metadaten-Volume, das jeden zugewiesenen Block auf seinen Speicherort abbildet, und dessen Größe wird bei der Anlage des Pools festgelegt. Es wächst mit der Zahl der zugewiesenen Blöcke und mit der Zahl der Snapshots, die sich diese Blöcke teilen — nicht mit der Datenmenge selbst. Ein Pool mit wenigen hundert Gibibyte Daten, aber hundert Snapshots, kann seine Metadaten erschöpfen, während der Datenbereich noch fast leer ist.

Der Ausfall ist schwerwiegender als eine reine Kapazitätserschöpfung. Ein Thin Pool, dessen Metadaten voll sind, nimmt keine Schreibvorgänge mehr an und muss in der Regel offline mit thin_check und thin_repair repariert werden, bevor er wieder verfügbar ist. lvs -o+metadata_percent zeigt den Wert an, und er verdient eine eigene Warnschwelle unterhalb der Datenschwelle, weil sich diese Erschöpfung — anders als volle Daten — nicht durch Löschen beheben lässt.

Drei Abzüge gehören vom Pool abgezogen, bevor die Gibibyte-Zahl aufgeteilt wird: Snapshot-Platz, dessen Bedarf von der Änderungsrate abhängt und nicht von der Datenmenge. Eine Füllobergrenze, weil die meisten Pools deutlich vor der vollen Kapazität langsamer werden. Und ausreichend freier Platz, um einen Rebuild, eine Migration oder eine Wiederherstellung abzuschließen — genau die Operation, die am wahrscheinlichsten ansteht, wenn der Pool ohnehin am vollsten ist.

Bei einem 10-TiB-Pool bleiben nach zwanzig Prozent Reserve für die Füllobergrenze und einem weiteren Tebibyte für Snapshots und Spielraum rund 7.168 GiB zum Verteilen — 71 Volumes zu 100 GiB statt 102. Diese Differenz ist groß genug, um sie im Voraus festzulegen, denn Speicherplatz aus bereits ausgegebenen Volumes zurückzuholen bedeutet, sie zu verkleinern, und Verkleinern ist die Operation, die üblicherweise nicht funktioniert.

Blockspeicher wird bei den meisten europäischen Cloud-Anbietern in ganzen Gibibyte bereitgestellt und pro bereitgestelltem Gibibyte-Monat abgerechnet, unabhängig von der tatsächlichen Nutzung. Eine Anfrage über 100 GiB wird mit 100 abgerechnet, ob ein einziges Gibibyte oder alle neunundneunzig beschrieben sind, und eine als 100 GB formulierte Anfrage gegen eine Schnittstelle, deren Einheit GiB ist, ergibt 7,4 Prozent mehr Kapazität und 7,4 Prozent mehr Kosten, als die dezimale Zahl vermuten ließ.

Dieselbe Rundung macht kleine Volumes in Summe unverhältnismäßig teuer. Fünfhundert Volumes zu 8 GiB sind 4.000 GiB bereitgestellt, also 3,9 TiB, und liegt die durchschnittliche Auslastung bei einem Viertel, sind drei Tebibyte der Rechnung leerer Platz. Auf weniger, größere Volumes mit einem gemeinsamen Dateisystem zu konsolidieren ist die übliche Antwort, und die Rechnung, die das begründet, ist genau diese Umrechnung, angewendet auf die bereitgestellten statt auf die genutzten Zahlen.

Größen zu wählen, die Zweierpotenzen oder zumindest saubere Bruchteile eines Tebibyte sind, macht die verbleibende Kapazität leicht nachvollziehbar. 10.240 GiB teilt sich exakt in Volumes zu 128, 256, 512, 1.024 oder 2.048 GiB und lässt am Ende nichts Unpassendes übrig. Eine als Standard gewählte Größe von 750 GiB dagegen lässt nach dreizehn Volumes 490 GiB übrig — zu wenig für ein vierzehntes und zu viel, um es zu ignorieren.

Dasselbe gilt für die darunterliegende Zuteilungseinheit. LVM-Extents, Thin-Pool-Chunk-Größen und Streifenbreiten haben alle eine eigene Granularität, die eine Volume-Größe entweder trifft oder nicht, und eine Größe, die eine ganze Zahl Gibibyte ist, ist auch bei jeder von ihnen eine ganze Zahl. Es ist die günstigste Form von Ordnung: Die Rechnung geht in beiden Fällen exakt auf, und nur die glatt teilende Version lässt sich in zwei Jahren noch nachvollziehen.

Ein Volume zu erweitern und anschließend das Dateisystem darauf zu vergrößern ist bei ext4, XFS und den meisten modernen Stacks eine Online-Operation, die Sekunden dauert. Der umgekehrte Weg ist eine andere Kategorie: Das Dateisystem muss zunächst alles vom Ende des Geräts wegräumen, bevor das Gerät selbst verkleinert werden kann — XFS kann das gar nicht, ext4 verlangt ein ausgehängtes Dateisystem. In der Praxis ist eine Volume-Größe eine Entscheidung in eine Richtung.

Diese Asymmetrie sollte die anfängliche Zuteilung prägen. Volumes klein zu starten und bei Bedarf zu vergrößern kostet ein paar Minuten je Erweiterung und hält den freien Platz des Pools dort verfügbar, wo er am meisten gebraucht wird; sie gleich auf eine geschätzte künftige Größe zu setzen bindet den Pool in Zuteilungen, die nie wieder freigegeben werden. Bei einem Thin Pool ist das Argument schwächer, weil ungenutzte Blöcke nicht verbraucht werden — aber die Metadaten und der psychologische Effekt eines Volumes, das 2 TiB frei meldet, gelten trotzdem.