TB in KiB 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 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 Terabyte sind 976.562.500 Kibibyte, exakt. 976.562.500 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 KiB sind 1.024 der Einheit darunter, ein kB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 0 TB und 0 TB — 2,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 kB 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.

Kein Speichersystem legt Dateien byteweise ab. Es vergibt Blöcke, und auf fast jedem modernen Dateisystem ist ein Block 4 KiB groß, weil das der Speicherseitengröße der zugrunde liegenden Architekturen entspricht. Die eigentlich nutzbare Lesart eines Terabytes ist deshalb nicht 1.000.000.000.000 Byte, sondern 244.140.625 Blöcke, und jede Frage danach, wie viel wirklich hineinpasst, führt auf diese Zahl zurück.

Die Division geht dabei restlos auf, was für diese Kategorie ungewöhnlich ist: Eine Billion enthält genug Zweierpotenzen, sodass ein Terabyte exakt 976.562.500 KiB und exakt 244.140.625 Blöcke ergibt, ohne Rest. Die meisten Umrechnungen zwischen dezimalen und binären Einheiten enden in einer langen Kommazahl — diese endet in einer runden Zahl, mit der sich weiterrechnen lässt.

Ein Digitalisierungsprojekt, das historische Akten oder Handschriften einscannt, erzeugt pro Blatt eine eigene Bilddatei, oft im niedrigen Megabyte-Bereich, gelegentlich deutlich darunter bei Vorschaubildern und Metadaten-Dateien. Bei mehreren Millionen Blättern — für ein einzelnes größeres Archiv keine ungewöhnliche Größenordnung — wird der letzte, nur teilweise gefüllte Block jeder Datei zu einer eigenen Rechnung: durchschnittlich ein halber Block, also rund 2 KiB, gehen pro Datei an Verschnitt verloren, egal wie klein die Datei selbst ist.

Bei einer Million Dateien sind das etwa 2 GiB reiner Blockverschnitt, bei hundert Millionen bereits 200 GiB — ein Fünftel eines Terabytes, bevor überhaupt etwas schiefgegangen ist. Für ein Digitalisierungsprojekt mit Metadaten-Dateien im dreistelligen Byte-Bereich neben jedem Bild ist diese Größenordnung keine Randnotiz, sondern ein eigener Posten in der Speicherplanung.

Bei Dateisystemen der ext-Familie wird die Anzahl der Inodes bei der Formatierung festgelegt und lässt sich danach nicht mehr ändern. Das Standardverhältnis reicht für gewöhnliche Nutzung großzügig aus und wird bei einem Datenbestand mit Millionen einzelner kleiner Dateien schnell zum Engpass: Schreibvorgänge scheitern mit einer Fehlermeldung über fehlenden Speicherplatz, während die Anzeige der freien Kapazität noch komfortabel aussieht — eine der verwirrenderen Fehlermeldungen, die ein Dateisystem produzieren kann.

Für ein geplantes Digitalisierungsprojekt ist das vor der Formatierung zu klären, nicht danach, denn eine Änderung der Inode-Zahl bedeutet in der Regel, das Dateisystem neu anzulegen. Eine grobe Schätzung der erwarteten Dateizahl aus der Anzahl der zu scannenden Blätter reicht, um den Wert bewusst statt am Standard vorbeizulegen — dieselbe Blockrechnung wie oben, nur gegen die erwartete Dateizahl statt gegen die Gesamtgröße gerechnet.

Unterhalb des Dateisystems hat das Speichermedium eine eigene Einheit. Festplatten sind von 512-Byte-Sektoren auf 4-KiB-Sektoren gewechselt, und viele bilden zur Kompatibilität weiterhin 512-Byte-Sektoren nach außen ab. Beginnt eine Partition an einem Offset, der kein Vielfaches der physischen Sektorgröße ist, überspannt jeder Dateisystemblock zwei physische Sektoren, und jeder Schreibvorgang wird zu einem Lesen-Ändern-Schreiben von beiden.

Der Effekt betrifft die Geschwindigkeit, nicht die Kapazität, und kann bei Schreibvorgängen erheblich sein. Moderne Partitionierungswerkzeuge richten standardmäßig auf 1 MiB aus, sodass das Problem inzwischen selten ist — es überlebt aber in lange zurückliegenden, unverändert übernommenen Partitionstabellen und lohnt eine Prüfung bei jedem Laufwerk, das langsamer arbeitet, als seine Hardware es sollte.

Die Kapazitätsplanung für ein großes Objektarchiv ist tatsächlich zwei Budgets, die beide gleichzeitig aufgehen müssen. Das Byte-Budget fragt, ob der Inhalt passt; das Objekt-Budget fragt, ob Block- und Metadaten-Zahlen ausreichen. Ein Terabyte fasst ein einziges File oder, am Blocklimit, 244 Millionen davon, und alles dazwischen hat einen anderen Metadatenaufwand, eine andere Backup-Dauer und eine andere Wiederherstellungszeit.

Das zweite Budget wird am häufigsten vergessen, weil es in keiner einzelnen Zahl auf einem Dashboard auftaucht. Ein Volumen bei vierzig Prozent seiner Byte-Kapazität kann trotzdem faktisch voll sein — ohne freie Inodes oder mit dem Großteil der Zeit in der Metadatenverwaltung —, und die Anzeige des freien Speichers, die die meisten im Blick behalten, meldet noch Entspannung, bis ein Schreibvorgang scheitert.

Ein zentraler Digitalisierungsdienst, der Bestände aus mehreren Archiven auf einer gemeinsamen Infrastruktur ablegt, profitiert davon, für alle Projekte dieselbe Blockgröße festzulegen, statt sie pro Bestand neu zu entscheiden. Ein einheitlicher Wert macht die Slack-Space-Rechnung für den gesamten Speicherbestand mit einer einzigen Formel überschlagbar, und er verhindert, dass ein später hinzugekommenes Projekt versehentlich auf einer anderen Blockgröße landet, deren Verschnitt sich erst bei der jährlichen Kapazitätsprüfung bemerkbar macht.

Die Wahl selbst folgt der erwarteten Dateigrößenverteilung des größten geplanten Bestands, nicht des Durchschnitts über alle. Ein Projekt mit hochauflösenden Handschriftenscans im zweistelligen Megabyte-Bereich verträgt eine größere Blockgröße gut; ein Projekt mit vielen kleinen Begleitdateien — Transkriptionen, Metadaten-XML, Vorschaubildern — leidet unter derselben Wahl überproportional. Wo beide Bestandstypen dieselbe Infrastruktur teilen, ist eine mittlere Blockgröße mit bewusst einkalkuliertem Verschnitt beim kleineren Bestand meist die tragfähigere Entscheidung als zwei getrennte Dateisysteme zu pflegen.

Die Zahlen auf dieser Seite sind vor allem im Voraus nützlich, weil die meisten Entscheidungen, die sie tragen, sich später nicht mehr ohne Neuanlage des Volumens korrigieren lassen. Blockgröße, Inode-Zahl und Ausrichtung werden bei der Anlage festgelegt. Eine zehnminütige Überschlagsrechnung — erwartete Dateizahl, erwartete Größenverteilung, daraus folgender Block- und Inode-Bedarf — entscheidet, ob ein Archiv jahrelang problemlos läuft oder mitten im Projekt migriert werden muss.

Für die meisten Digitalisierungsvorhaben genügt eine grobe Version. Liegt die erwartete Dateizahl im niedrigen Millionenbereich und die durchschnittliche Größe deutlich über 4 KiB, sind die Standardwerte ausreichend. Geht die Zahl in die hunderte Millionen, oder ist die durchschnittliche Datei kleiner als ein Block, reichen die Standardwerte nicht — und die Rechnung oben zeigt, um wie viel nicht.