GiB in KiB 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 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 Gibibyte sind 1.048.576 Kibibyte, exakt. 1.048.576 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 GiB sind 1.024 der Einheit darunter, ein GB sind 1.000. Auf dieser Seite ist das der Unterschied zwischen 1048576 KiB und 976562,5 KiB — 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.

Eine Partitionstabelle speichert Anfang und Länge in Sektoren. LVM verwaltet physische Extents. mdadm kennt eine Chunk-Größe in Kibibyte. Keines dieser Werkzeuge rechnet in der Einheit, in der jemand entscheidet, wie groß ein Volume sein soll — deshalb wird bei jeder Einrichtung eines NAS-Volumes oder eines Server-Storages mindestens einmal von Gibibyte auf eine kleinere Einheit umgerechnet, und meist gleich in zwei verschiedene.

Die Zahlen, die man dafür braucht, sind exakt: 1.048.576 KiB, 2.097.152 Sektoren zu 512 Byte und 262.144 Blöcke zu 4 KiB pro Gibibyte. Alle drei sind Zweierpotenzen, und genau das macht einen Rechenfehler tückisch — ein um den Faktor zwei verschobener Wert sieht immer noch aufgeräumt aus und fällt erst auf, wenn man ihn gegen die Gesamtkapazität prüft.

Lange begann die erste Partition auf einer PC-Festplatte bei Sektor 63, weil die vom BIOS gemeldete Geometrie 63 Sektoren pro Spur vorsah und die erste Spur den Bootsektor trug. 63 ist ungerade, also war jede daraus abgeleitete Grenze ungerade — und als Laufwerke intern auf 4-KiB-Sektoren umstiegen, aber weiterhin 512-Byte-Sektoren nach außen meldeten, lag praktisch jeder Dateisystemblock über zwei physischen Sektoren verteilt.

Der Start bei Sektor 2048 — genau ein Mebibyte weiter — behebt das, weil dieser Versatz durch jede in der Praxis vorkommende Granularität teilbar ist: 4-KiB-Sektoren, größere Flash-Seiten, 512-KiB-RAID-Chunks, 4-MiB-LVM-Extents. Der Preis ist ein Mebibyte Festplatte, bei Gibibyte-Größen ein Rundungsfehler, und jedes gängige Partitionierungswerkzeug setzt seit über einem Jahrzehnt standardmäßig dort an.

Die Strafe ist ein Read-Modify-Write-Zyklus, und sie trifft Schreibzugriffe, nicht Lesezugriffe. Ein Laufwerk mit 4-KiB-Sektoren kann nicht weniger als einen davon schreiben, also zwingt ein Dateisystemblock, der zwei physische Sektoren überlappt, das Laufwerk dazu, beide zu lesen, die neuen Daten einzufügen und beide zurückzuschreiben. Bei Flash-Speicher heißt die entsprechende Einheit Erase Block, und die Verstärkung fällt größer aus, weil der Controller deutlich mehr umlagern und irgendwann löschen muss, als tatsächlich geschrieben wurde.

Nichts davon zeigt sich in einer Kapazitätsangabe oder im Ausgabefenster von df — das Volume funktioniert und meldet exakt die erwartete Größe. Sichtbar wird es als Schreibdurchsatz, der bei zufälligen Zugriffen einen Bruchteil dessen erreicht, was die Hardware verspricht. parted /dev/sda align-check optimal 1 beantwortet die Frage direkt, cat /sys/block/sda/queue/optimal_io_size liefert die vom Laufwerk bevorzugte Granularität.

LVM vergibt Speicher standardmäßig in physischen Extents zu 4 MiB, also ist ein 100-GiB-Logical-Volume 25.600 Extents groß, und jede Größe, die kein Vielfaches von 4.096 KiB ist, wird auf den nächsten Extent aufgerundet. Deshalb liefern lvcreate -L 10G und lvcreate -L 10GiB denselben Wert, während lvcreate -l 100%FREE eine Zahl ergibt, die auf den ersten Blick willkürlich wirkt — in Extents ist sie exakt, in Gibibyte unrund.

RAID kommt mit einer eigenen Granularität dazu. mdadm setzt standardmäßig einen 512-KiB-Chunk, und ein Stripe über n Datenplatten ist n Chunks breit, also hat ein fünf Platten umfassendes RAID 5 einen 2-MiB-Stripe. Das sollte man mkfs mitteilen: mkfs.ext4 nimmt Stride und Stripe-Width in Dateisystemblöcken entgegen, und wer diese Werte richtig setzt, vermeidet, dass jeder volle Stripe-Schreibvorgang erst die Parität nachlesen muss.

Am sichersten ist es, den Einheiten-Suffix mitzugeben und das Werkzeug rechnen zu lassen. parted akzeptiert KiB, MiB, GiB und TiB direkt, und parted -a optimal setzt die Grenze selbständig auf die richtige Granularität. sfdisk versteht K-, M- und G-Suffixe, die binär gemeint sind. mkfs.ext4 verlangt dagegen eine Blockanzahl, also wird aus einer Gibibyte-Angabe 262.144 Blöcke pro GiB — und ein Zahlendreher dabei erzeugt ein Dateisystem, das zwar passt, die Partition aber nicht ausfüllt.

Wo eine nackte Zahl unvermeidlich ist, gehört die Gibibyte-Angabe als Kommentar daneben. Ein Layout-Skript voller Werte wie 2097152 und 209715200 ist korrekt und vollständig undurchsichtig, und die nächste Person, die es ändert, rechnet garantiert nur eine der beiden Zahlen um. Die Arithmetik ist in beide Richtungen exakt; verloren geht die Dokumentation.

Eine 100-GiB-Partition sind 104.857.600 KiB, und ein frisches ext4-Dateisystem darauf meldet spürbar weniger. Das Journal beansprucht bei dieser Größenordnung meist 128 MiB fest. Die Inode-Tabellen werden standardmäßig mit einem Inode je 16 KiB zu je 256 Byte im Voraus angelegt — rund 1,6 GiB bei einem 100-GiB-Volume. Fünf Prozent sind standardmäßig für root reserviert, was tune2fs -m auf einem reinen Datenvolume senken kann.

Das ergibt fast sieben Gibibyte, die vor dem ersten geschriebenen Byte bereits verplant sind, und keiner davon ist Verlust — es ist die Struktur, die das Dateisystem arbeiten lässt, plus eine Reserve, die verhindert, dass eine volle Platte unrettbar wird. Ist auf dem Volume ohnehin nur eine kleine Zahl großer Dateien geplant, senkt mkfs.ext4 -T largefile die Inode-Anzahl deutlich und gibt den größten Teil der Tabelle wieder frei.