Mastodon Media Storage: Woher kommt der Overhead im Minio S3 Speicher?

Gestern habe ich mir ein kleines Tool geschrieben, das ermittelt, wie die Dateigrößenverteilung in meinem metalhead.club S3 Storage ist.

Wichtig: Das bezieht sich auf den Storage-Layer von meinem Minio-Server - nicht direkt auf die Dateien, wie sie hochgeladen wurden. Minio legt noch Metadateien dazu bzw. integriert kleinere Dateien in eigene Strukturen und legt diese dann im Dateisystem ab. Siehe: Working with Small Objects in AI/ML workloads

Ich wollte trotzdem mal sehen, wie viel Speicher durch Blocksize-Overhead verloren geht.

root@s3 /root # time ./filesize-analyzer /mnt/s3storage1/metalheadclub-media 
Dateigrößenstatistik:
>= 1024K: 136138 Dateien
< 1K: 913982 Dateien
< 2K: 53357 Dateien
< 4K: 99581 Dateien
< 8K: 182476 Dateien
< 16K: 383095 Dateien
< 32K: 646094 Dateien
< 64K: 711153 Dateien
< 128K: 419150 Dateien
< 256K: 389334 Dateien
< 512K: 260465 Dateien
< 1024K: 134658 Dateien

Theoretische Gesamtgröße der Dateien kleiner als 4K: 766435063 Bytes
Tatsächliche Gesamtgröße der Dateien kleiner als 4K: 4370104320 Bytes

./filesize-analyzer /mnt/s3storage1/metalheadclub-media  100,41s user 1157,35s system 21% cpu 1:36:57,26 total

Das Ergebnis: 1.066.920 Dateien sind kleiner als die Dateisystem-Blocksize von 4K (ext4). Diese brauchen also beim Ablegen im Dateisystem mehr Speicher, als sie eigentlich groß sind. Das kommt daher, dass für jede Datei - auch wenn sie kleiner ist - im Dateisystem mindestens 4 KB (Kilobyte, 4 x 1024 bytes) reserviert werden. All diese Dateien erzeugen also einen Overhead.

Durch den Vergleich in den letzten beiden Zeilen wird klar, wie groß der Overhead ist: Eigentlich sind die betreffenden Dateien nur 766435063 Bytes (= 731 MB) groß, doch der Blocksize-Overhead im Dateisystem führt dazu, dass diese real 4370104320 Bytes (= 4167 MB) belegen. Das ist 570 % ihrer eigentlichen Größe.

Übrigens ist das nicht die ganze Geschichte: Mein Tool berücksichtigt im Moment noch keine Bruchstücke von Dateien, die größer oder gleich 4K sind. Eigentlich kommt nämlich auch bei den größeren Dateien noch Overhead durch die Blocksize dazu. Nämlich dann, wenn ihre Größe nicht genau ein vielfaches von 4K ist. Im Fall der größeren Dateien spielt der Overhead im Verhältnis zur abgespeicherten Datenmenge allerdings kaum mehr eine Rolle, daher habe ich ihn bei der Auswertung ignoriert. Besonders dramatisch Fällt der Overhead bei den ganz kleinen Dateien aus.

Wie ihr an der letzten Zeile der Ausgabe erkennen könnt, hat die Auswertung des metalhead.club Media Storage knapp über 1,5 Stunden gedauert. Das ist nicht besonders schnell - allerdings liegen im Storage auch etwa 4,3 Millionen Dateien, die einzeln auf ihre Größe untersucht wurden - dazu noch verschachtelt in relativ tiefen Verzeichnishierarchien.

Mein Tool zur Analyse ist bisher nur ein Proof of concept. Womöglich habe ich noch den ein oder anderen Bug in meinem Code. Die Berechnung sieht realistisch aus, doch ich hoffe, noch bessere Performance herauskitzeln zu können. Da gibt es sicherlich noch Verbesserungspotential. Daher habe ich es noch nicht veröffentlicht. Sollte ich aber einmal zufrieden damit sein, steht einer Veröffentlichung natürlich nichts im Wege. Interessanterweise konnte ich auf die Schnelle kein solches Tool finden, das einem eine kleine Statistik über die Dateigrößen in einem Verzeichnis liefert. Vielleicht habe ich auch nur nicht genau genug gesucht …

Auf das Thems bin ich übrigens gekommen, nachdem das Monitoring meines S3 Servers Alarm schlug, da nicht mehr besonders viel Speicher auf dem SSD-Speicher frei war. Ich war verwundert und habe (zu einem früheren Zeitpunkt) kurz die Größenangaben der verschiedenen Systeme verglichen.

Mastodon sagt: 603 GiB Medien gespeichert
Minio S3 sagt: 692 GiB Medien gespeichert
Filesystem sagt: 763 GiB Medien gespeichert

Da die Angaben zum Speicherverbrauch so stark abwichen, begab ich mich auf Spurensuche. Wie konnte es sein, dass Mastodon der Meinung war, dass es nur 603 GiB an Medien besaß, aber das Dateisystem mit 763 GiB deutlich mehr belegt war? Ich hoffte, darauf eine Antwort zu finden. Da Mastodon sehr viele sehr kleine Dateien abspeichert (Vorschaubilder, Avatare, …), lag mein Verdacht auf dem Blocksize-Overhead. Wie ihr seht, ist dieser im Verhältnis zur Originaldateigröße beträchtlich. Aber nicht bedeutend genug, als dass er zumindest die 763-692 GiB = 71 GiB Unterschied zwischen Minio und Filesystem erklären könnte. Denn bezogen auf meinen konkreten Fall bedeutet das nur, dass ich nur ca 3.4 GB mehr belege, als theoretisch nötig - nicht 71 GiB.

Und dann wäre da noch der Unterschied zwischen Mastodon und Minio. Der könnte evtl. an verwaisten Dateien liegen, die zwar noch im Minio S3 Speicher liegen, aber von denen Mastodon aus irgendeinem Grund nichts mehr weiß. Ich habe zwar ein tootctl media remove-orphans ausgeführt, das den Speicher um solch verwaiste Dateien eigentlich bereinigen sollte. Doch dabei sind auch nur 2.8 GB Speicher frei geworden.

Falls sich jemand tiefergehend in der Materie auskennt: Schreibt mich gerne an! Entweder auf Mastodon (thomas@metalhead.club) oder per E-Mail. Würde mich freuen, wenn ich mir die Unterschiede erklären könnte.