GiB in TiB 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 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.

In dieser Richtung wird geteilt, und zwar durch eine ganze Zahl: 1.024 davon passen restlos in ein Tebibyte. 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 GiB sind 1.024 der Einheit darunter, ein GB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 0,001 TiB und 0,0009 TiB — 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.

Platten werden in dezimalen Terabyte verkauft, Pools in binären Einheiten gezählt, und der erste Effekt beim Zusammenbau ist ein zehnprozentiger "Verlust", der gar keiner ist. Eine 4-TB-Platte enthält exakt 4.000.000.000.000 Byte wie beworben, das sind 3.725,29 GiB oder 3,638 TiB. Acht davon sind 29.802 GiB oder 29,10 TiB, während auf der Rechnung 32 TB steht – zwischen diesen beiden Zahlen ist nichts verloren gegangen, es sind dieselben Bytes in unterschiedlichen Basen gezählt.

Die zweite Umrechnung nimmt echte Kapazität weg: Parität oder Spiegelung, die Reserve, die das Dateisystem einbehält, und die Füllgrenze, an die sich jeder Betreiber halten sollte. Wer beide sauber trennt, kann seine Kapazitätsplanung nachvollziehbar machen – erst die Rohzahl in TiB nennen, dann jeden Abzug mit Begründung, statt eine Zahl zu präsentieren, die 40 Prozent unter der Rechnung liegt, ohne dass jemand nachrechnen kann, warum.

Das ist die häufigste Ursache für einen Gibibyte-Wert, der sich nicht aufgeht. zpool list zeigt die Rohgröße der Vdevs inklusive Parität, weil das die Ebene ist, die den Pool verwaltet. zfs list zeigt, was die Datei-Ebene tatsächlich speichern kann, Parität ausgeklammert. Auf einem Achtplatten-raidz2-Pool zeigt Ersteres rund ein Drittel mehr als Letzteres, und beide Angaben sind korrekt.

Für die Planung folgt daraus eine einfache Regel: die Zahl von der Ebene nehmen, die zur Frage passt. Wie viele Daten hineinpassen, ist eine zfs list-Frage. Ob eine Ersatzplatte groß genug ist, ist eine zpool list-Frage. Wer die falsche in Tebibyte umrechnet und in eine Planung einträgt, bekommt ein Array, das ein Drittel früher voll läuft, als die Tabelle versprochen hat.

Die grobe Rechnung ist einfach: eine Spiegelung liefert die Hälfte, RAID 5 und raidz1 liefern n − 1 Platten Nutzdaten, RAID 6 und raidz2 liefern n − 2. Acht Platten zu 3.725,29 GiB geben in raidz2 sechs Platten Nutzdaten, 22.351 GiB oder 21,83 TiB; dieselben acht Platten als vier gespiegelte Paare geben 14.901 GiB oder 14,55 TiB, dafür mit deutlich besserem Wiederherstellungsverhalten.

Padding nimmt danach noch einen weiteren Anteil, den die grobe Rechnung nicht erfasst: ZFS legt in Blöcken an, die aus der Sektorgröße abgeleitet sind, und Datensätze, die sich nicht sauber über die Datenplatten verteilen, hinterlassen Lücken. Bei einem Fileserver mit der Standard-Blockgröße von 128 KiB ist der Verlust klein; bei einer Datenbank mit 8-KiB-Blockgröße auf Platten mit ashift=12 kann er ein Fünftel der Nennkapazität erreichen – ein Wert, den man vor dem Aufbau des Pools durchrechnen sollte, nicht erst danach entdeckt.

Ein Copy-on-Write-Dateisystem kann eine Datei nicht durch Überschreiben freigeben – es muss neue Metadaten schreiben, und dafür braucht es freien Platz. Ein Pool, der wirklich auf null Restplatz käme, könnte deshalb nichts mehr löschen. ZFS verhindert das, indem es standardmäßig ein Zweiunddreißigstel des Pools zurückhält, das normale Schreibvorgänge nicht anrühren.

Bei einem 32-TiB-Pool sind das rund 1 TiB, die im Wert, den Nutzer als frei sehen, gar nicht auftauchen. Es ist ein fester Anteil, kein fester Betrag, wächst also mit dem Pool und gehört als eigener Posten in jede Kapazitätsplanung. Btrfs hat ein vergleichbares Problem und löst es über eine globale Reserve, aber der zugrunde liegende Zwang gilt für jedes Dateisystem, das nie an Ort und Stelle überschreibt.

Die Zuteilungsleistung eines Copy-on-Write-Pools sinkt, je mehr der freie Platz zersplittert – und sie sinkt nicht allmählich, sondern deutlich spürbar. Die übliche Empfehlung lautet, einen Allzweck-Pool auf rund achtzig Prozent zu planen, bei starker zufälliger Schreiblast eher weniger.

Das macht aus 32 TiB nutzbarer Kapazität rund 25,6 TiB Planungskapazität, und wer den Unterschied als Reserve für eine hektische Phase behandelt, endet mit einem Pool, der langsam wird und sich schwer wiederherstellen lässt. Wer die Gibibyte-Summe direkt in die Füllgrenze umrechnet, hat eine einzige Zahl zum Planen; wer die Rohzahl stehen lässt, lädt förmlich dazu ein, sie zu nutzen.

Ein Pool wächst nicht um einen frei wählbaren Betrag. Kapazität kommt entweder als weiteres Vdev derselben Form dazu, oder jede Platte in einem bestehenden Vdev wird gegen eine größere getauscht, wobei sich der Pool erst nach der letzten Platte vergrößert. Neuere ZFS-Versionen können einer bestehenden raidz-Vdev eine einzelne Platte hinzufügen, doch die bereits vorhandenen Daten behalten ihr altes Paritätsverhältnis, bis sie neu geschrieben werden.

Für die Planung bedeutet das: Der Wachstumsschritt ist groß und im Voraus bekannt. Eine Acht-Platten-raidz2-Vdev aus 4-TB-Platten fügt jeweils 21,83 TiB hinzu, eine Planung, die in achtzehn Monaten an ihre Grenze stößt, hat also eine Beschaffungsentscheidung in einer diskreten Größe vor sich, nicht in einer Rate. Den Schritt frühzeitig in Tebibyte durchzurechnen, macht sofort klar, ob als Nächstes ein Vdev reicht oder zwei nötig sind.