TiB in KiB 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 Kibibyte sind exakt 1.024 Byte. Der Name wurde 1998 eingeführt, damit „Kilobyte" wieder 1.000 bedeuten kann — durchgesetzt hat sich die Gewohnheit nie ganz.

In dieser Richtung wird multipliziert, und zwar mit einer ganzen Zahl: ein Tebibyte sind 1.073.741.824 Kibibyte, exakt. 1.073.741.824 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 1073741824 KiB und 976562500 KiB — 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.

Dreißig Bit trennen die beiden Einheiten, sodass ein Tebibyte zu 1.073.741.824 Kibibyte wird — eine Zahl, die niemand auf einen Blick liest. Zwei Tebibyte sind 2147483648, fünf sind 5368709120, zehn sind 10737418240. Das sind die Werte, die in das Kontingentfeld eines Hochschulrechenzentrums eingetragen werden, und das Feld nimmt jede Ganzzahl ohne Widerspruch entgegen — auch eine mit einer Ziffer zu viel, was der Fehler ist, der in der Praxis tatsächlich passiert.

Die Gewohnheit, die ihn abfängt, ist Ziffern zählen statt Zahlen lesen. Ein Mebibyte sind vier Stellen Kibibyte, ein Gibibyte sieben, ein Tebibyte zehn. Jede Einheit fügt annähernd drei hinzu, sodass ein als niedrig-einstellig-Tebibyte gemeintes Kontingent zehn oder elf Stellen haben sollte — alles andere liegt um eine Zehnerpotenz daneben, bevor überhaupt auf den Wert selbst geschaut wurde.

Blockgrenzen in setquota, edquota und repquota sind Zählungen von 1.024-Byte-Einheiten, unabhängig davon, welche Blockgröße das darunterliegende Dateisystem tatsächlich verwendet. Diese Entkopplung ist beabsichtigt: Ein Kontingent, das auf einem ext4-Volumen mit 4-KiB-Blöcken gesetzt wird, und eines auf einem Dateisystem mit 64-KiB-Blöcken bedeuten dieselbe Speichermenge — verschiebt das Rechenzentrum ein Nutzerverzeichnis zwischen beiden Systemen, ändert sich das zugesagte Kontingent nicht.

Das heißt auch, dass die gemeldeten Zahlen nicht mit der eigenen Buchführung des Dateisystems übereinstimmen: Ein Nutzer, der 1.000 Blöcke zu 4 KiB belegt, erscheint mit 4.000 Quota-Blöcken. XFS führt eine eigene Quota-Implementierung mit derselben Einheit, aber eigener Werkzeugkette — xfs_quota -c 'limit bhard=2t user=alice' akzeptiert eine Endung und rechnet selbst, was der bessere Weg ist, wo verfügbar.

Das weiche Limit ist eine Warnung mit Frist. Ein Nutzer, der es überschreitet, arbeitet zunächst weiter, während eine Karenzzeit läuft — standardmäßig sieben Tage —, und wenn diese abläuft, verhält sich das weiche Limit wie ein hartes. Das harte Limit greift sofort: Der Schreibvorgang gibt EDQUOT zurück, was Anwendungen meist als „Datenträger voll" melden, was Studierende zunächst dazu bringt, den freien Speicherplatz zu prüfen und reichlich davon zu finden.

Zwischen beiden Werten liegt die eigentliche Entscheidung eines Rechenzentrums. Ein weiches Limit bei 1,8 TiB und ein hartes bei 2 TiB geben 214.748.364 Kibibyte Spielraum und eine Woche Zeit, ihn zu nutzen — genug, damit jemand die Warnung bemerkt und aufräumt. Beide Werte gleich zu setzen entfernt die Warnphase vollständig, und das erste Anzeichen dafür ist dann ein fehlgeschlagener Abgabetermin statt einer Meldung im System.

Jedes Kontingent hat ein zweites Zahlenpaar, das nicht Kilobyte, sondern Dateien zählt, und die beiden Grenzen sind unabhängig voneinander. Ein Nutzer, der sein 2-TiB-Blockkontingent kaum ausschöpft, kann trotzdem einen Schreibvorgang verweigert bekommen, weil das Inode-Limit erreicht ist — und die Fehlermeldung ist dieselbe, ohne Hinweis darauf, welche Grenze tatsächlich getroffen wurde. quota -s zeigt beide, und das ist der erste Befehl, wenn ein Nutzer beteuert, noch Platz zu haben.

Das Inode-Limit existiert, weil Inodes eine feste Ressource sind, die bei der Anlage des Dateisystems zugeteilt wird und sich später nicht erweitern lässt. Ein einzelnes Konto, das zehntausende winziger Dateien anlegt — etwa aus einem fehlkonfigurierten Job — kann sie erschöpfen, während es nur einen verschwindenden Anteil des Blockkontingents nutzt, und dann kann niemand auf dem Laufwerk mehr eine neue Datei anlegen. Ein Inode-Limit schützt deshalb das Dateisystem, nicht in erster Linie den einzelnen Nutzer.

Manche Werkzeuge in diesem Bereich akzeptieren eine Endung, manche nicht, und das zu wissen ist mehr wert als die Umrechnung selbst. xfs_quota akzeptiert k, m, g und t und behandelt sie binär. Neuere setquota-Versionen akzeptieren dieselben Endungen auf der Kommandozeile. edquota öffnet einen Editor mit einer Tabelle nackter Ganzzahlen, und jeder dort eingetragene Wert ist in Kibibyte. ZFS umgeht die Frage vollständig — zfs set quota=2T ist eine Dataset-Eigenschaft mit eigenem Parser.

Wo die nackte Ganzzahl unvermeidbar ist, lohnt es sich, die Tebibyte-Zahl daneben zu notieren. Eine Kontingenttabelle mit 2147483648 und 2147483648 ist korrekt und unüberprüfbar; dieselbe Tabelle mit einem Kommentar „2 TiB weich, 2 TiB hart" lädt dazu ein, aufzufallen, dass das weiche Limit niedriger hätte liegen sollen. Die Rechnung ist in beiden Fällen exakt und sofort erledigt — es geht nur darum, ob die nächste Person erkennen kann, was gemeint war.

An einem Hochschulrechenzentrum wird ein Kontingent selten nur für eine einzelne Person gesetzt, sondern häufig für eine Arbeitsgruppe oder ein Institut, deren Mitglieder gemeinsam auf ein Verzeichnis zugreifen. Die Kibibyte-Zahl, die dabei ins Feld eingetragen wird, ergibt sich aus einer Schätzung über mehrere Nutzer hinweg — Forschungsdaten, Simulationsergebnisse, Rohdaten aus Messreihen — und die Unsicherheit in dieser Schätzung ist meist größer als jede Rundungsfrage zwischen Kilobyte und Kibibyte.

Trotzdem lohnt sich die exakte Rechnung gerade hier, weil ein Gruppenkontingent selten einzeln nachjustiert wird, sondern über Jahre stehen bleibt. Ein Wert, der beim Anlegen um zehn Prozent zu niedrig gesetzt wurde, weil er versehentlich aus einer dezimalen statt einer binären Terabyte-Zahl abgeleitet wurde, fällt oft erst auf, wenn die Arbeitsgruppe mitten in einer Deadline an die Grenze stößt — und eine nachträgliche Erhöhung braucht in der Regel einen eigenen Antrag beim Rechenzentrum.

Ein Blockkontingent begrenzt, wie viel jemand speichert, und nichts daran begrenzt, wie viel geschrieben wird. Ein Job, der wiederholt große temporäre Dateien anlegt und löscht, bleibt dauerhaft innerhalb eines 2-TiB-Kontingents und erzeugt dabei erhebliche Schreiblast, die Flash-Speicher verschleißt und Snapshots mit Änderungsverkehr füllt. Geht es um Durchsatz oder Gerätelebensdauer statt um Kapazität, ist das Kontingentfeld nicht der richtige Hebel, und keine Umrechnung macht es dazu.

Snapshots verkomplizieren die Grenze in die andere Richtung. Auf einem Copy-on-Write-Dateisystem wird gelöschte, aber noch von einem Snapshot referenzierte Daten weiterhin irgendjemandem angelastet, und je nach Zuordnung des Kontingents unter Umständen genau dem Nutzer, der sie gelöscht hat. Wer ein Tebibyte an Dateien entfernt hat und keine Veränderung der eigenen Nutzung sieht, schaut in der Regel genau darauf — und die Lösung ist eine Aufbewahrungsregel für Snapshots, keine höhere Zahl im Blockfeld.