show size of directory linux

Es war drei Uhr morgens an einem Dienstag, als das Telefon klingelte. Ein Junior-Admin bei einem mittelständischen Cloud-Anbieter in Frankfurt hatte versucht, auf einem überlasteten Dateiserver mit vier Petabyte Daten den Platzfresser zu finden. Er tippte blindlings Befehle ein, um Show Size Of Directory Linux zu erzwingen, ohne zu ahnen, dass er gerade eine Lawine auslöste. Er schickte einen rekursiven Befehl ohne Tiefenbegrenzung direkt in ein gemountetes Netzwerkdateisystem mit Millionen von winzigen Logdateien. Das Ergebnis? Die IO-Wait-Werte schossen so extrem in die Höhe, dass die Datenbank-Anwendungen auf demselben Host die Verbindung verloren. Ein ganzer Cluster ging für zwei Stunden in die Knie, nur weil jemand wissen wollte, welcher Ordner zu groß ist. Ich habe solche Szenarien in den letzten fünfzehn Jahren immer wieder erlebt. Wer glaubt, die Abfrage der Verzeichnisgröße sei eine triviale Aufgabe, die man mal eben nebenbei erledigt, spielt russisches Roulette mit der Systemperformance.

Der blinde Glaube an einfache Befehle für Show Size Of Directory Linux

Der häufigste Fehler, den ich sehe, ist das blinde Vertrauen in den Standardbefehl du -sh *. In der Theorie klingt das logisch: „Disk Usage“, „Summarize“, „Human Readable“. In der Praxis auf einem Produktivsystem ist das oft der Anfang vom Ende. Warum? Weil dieser Befehl jeden einzelnen Inode anfassen muss. Wenn du in einem Verzeichnis mit drei Millionen kleinen Dateien arbeitest – was bei modernen Web-Apps oder Mailservern völlig normal ist – rattert die Festplatte sich zu Tode, während der Admin ungeduldig auf den Cursor starrt.

Ich erinnere mich an einen Fall, bei dem ein Kollege diesen Befehl auf einem Backup-Volume ausführte. Nach zehn Minuten ohne Rückmeldung drückte er Strg+C. Was er nicht wusste: Der Kernel war bereits damit beschäftigt, riesige Mengen an Metadaten in den Cache zu schaufeln. Das System war für andere Prozesse blockiert, obwohl der Befehl scheinbar abgebrochen war.

Die Lösung ist hier nicht der Verzicht, sondern die Präzision. Profis nutzen die Option --max-depth=1. Das verhindert, dass das System tiefer gräbt, als es für den ersten Überblick nötig ist. Wer direkt in die Tiefe geht, ohne die Struktur zu kennen, verbrennt Zeit und Ressourcen. Es ist, als würde man ein ganzes Haus abreißen, nur um zu sehen, ob im Keller eine Kiste steht. Man fängt oben an und arbeitet sich Schicht für Schicht nach unten.

Die Falle der scheinbaren Wahrheit durch Blockgrößen

Ein weiterer massiver Denkfehler liegt im Verständnis dessen, was Linux eigentlich misst. Viele Admins verwechseln die tatsächliche Dateigröße mit dem belegten Platz auf dem Datenträger. Ich habe Kunden gesehen, die hunderte Euro in Speichererweiterungen investiert haben, weil sie dachten, ihre Verzeichnisse seien voll, obwohl sie nur Opfer von Fragmentierung oder massiven Sparse-Files waren.

Linux speichert Daten in Blöcken, meistens 4 Kilobyte groß. Wenn du eine Datei hast, die nur 1 Byte groß ist, belegt sie trotzdem 4 Kilobyte auf der Platte. In einem Verzeichnis mit einer Million solcher Dateien zeigt dir ein naiver Befehl zur Ermittlung der Größe einen gigantischen Platzverbrauch an, während die Summe der Dateigrößen winzig ist. Wenn du dann versuchst, den Platz durch das Löschen von „großen“ Dateien freizugeben, die eigentlich nur aus Nullen bestehen (Sparse-Files), wunderst du dich, warum die Anzeige für den freien Speicherplatz sich keinen Millimeter bewegt.

In meiner Laufbahn war das oft ein Grund für Fehlentscheidungen beim Hardware-Kauf. Da wurden neue SAN-Systeme bestellt, weil die Verzeichnisse laut einfacher Abfrage „voll“ waren. Hätten sie die Schalter für die tatsächliche Schein-Größe (--apparent-size) genutzt, hätten sie gesehen, dass das Problem bei der Dateisystemkonfiguration lag und nicht am mangelnden Platz.

Vernachlässigte Dateisystem-Quotas und Inode-Erschöpfung

Das ist der Klassiker: Der Befehl zeigt noch 500 Gigabyte freien Platz an, aber das System meldet „No space left on device“. Ein Admin, der sich nur auf Show Size Of Directory Linux verlässt, um die Speicherbelegung zu verstehen, übersieht die Inodes. Jedes Dateisystem hat eine begrenzte Anzahl an Index-Knoten. Wenn du Millionen kleiner Dateien erzeugst, gehen dir die Inodes aus, bevor der Speicherplatz knapp wird.

Ich habe das bei einem großen deutschen E-Commerce-Anbieter erlebt. Die Sessions wurden als kleine Dateien in einem Verzeichnis abgelegt. Die Größenabfrage sagte: „Alles super, kaum Platz belegt.“ Dennoch stürzte der Shop ab. Der Befehl df -i hätte die Wahrheit ans Licht gebracht: 100% Inode-Belegung.

Die Lösung ist ein radikaler Wechsel der Perspektive. Man darf nicht nur nach Gigabytes schauen. Man muss nach der Anzahl der Einträge schauen. Wer das ignoriert, wird von einem „leeren“ Server überrascht, der trotzdem keine einzige Datei mehr annehmen kann. Das ist besonders tückisch in Containervirtualisierungen wie Docker, wo Layer oft unbemerkt Inodes fressen.

Performance-Killer: Netzwerk-Mounts und NFS-Latenzen

Wer versucht, die Größe eines über das Netzwerk gemounteten Verzeichnisses (NFS oder SMB) mit Standard-Tools zu ermitteln, kann direkt seinen Kündigungsbrief schreiben, wenn er das zur falschen Zeit macht. Über das Netzwerk ist jede Metadaten-Abfrage ein teurer Roundtrip. Während eine lokale SSD tausende Abfragen pro Sekunde schafft, kriecht ein NFS-Share bei einer rekursiven Größenmessung dahin.

Ein Vorher/Nachher-Vergleich verdeutlicht das Problem: Ein Admin möchte wissen, warum das Backup-NAS voll ist. Er nutzt den Standardansatz und startet eine rekursive Suche über das gesamte Root-Verzeichnis des Mounts. Die Netzwerklast steigt sofort an, da für jede Datei ein stat-Call über die Leitung geht. Die Latenz für andere Nutzer des NAS steigt von 2ms auf 200ms an. Nach drei Stunden bricht der Prozess ab, weil das Netzwerk-Timeout zuschlägt. Er hat kein Ergebnis, aber alle Nutzer verärgert.

Der richtige Ansatz wäre gewesen, die Analyse auf der Serverseite des NAS direkt auszuführen oder, falls das nicht möglich ist, Tools zu nutzen, die parallel arbeiten oder Caching-Mechanismen besitzen. Er hätte erst die oberste Ebene prüfen sollen, um den Übeltäter einzugrenzen. Anstatt das gesamte System zu scannen, hätte er gezielt die drei größten Unterverzeichnisse identifiziert und dort weitergemacht. Zeitaufwand: 5 Minuten. Belastung für andere: Minimal.

Automatisierung ohne Verstand führt zum Monitoring-Gau

Viele Teams versuchen, die Überwachung der Verzeichnisgrößen zu automatisieren. Sie schreiben Cronjobs, die alle 15 Minuten durch das Dateisystem pflügen, um Statistiken zu sammeln. Das klappt bei 10 Gigabyte super. Bei 10 Terabyte wird der Cronjob zum Denial-of-Service-Angriff gegen sich selbst.

Ich habe Systeme gesehen, auf denen drei Instanzen desselben Skripts gleichzeitig liefen, weil die erste Instanz nicht fertig wurde, bevor die nächste startete. Die Festplatten-Köpfe kamen aus dem Schwingen nicht mehr heraus. Wenn man Verzeichnisgrößen überwachen will, nutzt man keine rekursiven du-Scans in kurzen Intervallen. Man nutzt Dateisystem-Events oder Quotas, die vom Kernel in Echtzeit mitgeschrieben werden.

• Nutze ncdu für interaktive Suchen, aber niemals automatisiert auf riesigen Mounts.
• Baue Sicherheitsabfragen in Skripte ein (z.B. Prüfen, ob eine Instanz bereits läuft).
• Setze Timeouts für jeden Befehl, der das Dateisystem scannt.
• Bevorzuge immer die Abfrage von Metadaten, die das Dateisystem ohnehin schon kennt.

Realitätscheck

Erfolgreiches Ressourcenmanagement unter Linux hat wenig mit dem Auswendiglernen von Flags zu tun. Es geht um das Verständnis der zugrunde liegenden Hardware und des Kernels. Wer glaubt, mit einem schnellen Befehl immer die Wahrheit zu erfahren, wird irgendwann ein System im denkbar ungünstigsten Moment lahmlegen.

In der echten Welt der Systemadministration gibt es keine „Ein-Klick-Lösung“ für Dateisystemanalysen auf Enterprise-Niveau. Du musst wissen, wie viele Inodes du hast, wie groß deine Blöcke sind und ob dein Speicher lokal oder im Netz liegt. Wenn du das ignorierst, sparst du heute vielleicht zwei Minuten Recherche, zahlst dafür aber morgen mit einer nächtlichen Notfallschicht oder verlorenen Kundendaten. Ein guter Admin ist nicht der, der am schnellsten tippt, sondern der, der weiß, wann er einen Befehl besser nicht abschickt. Es braucht Disziplin, immer erst die Auswirkungen auf die IO-Last zu prüfen, bevor man tief grabende Analysen startet. Wer diese Disziplin nicht aufbringt, wird zwangsläufig scheitern – das ist keine Drohung, sondern eine statistische Gewissheit aus jahrzehntelanger Praxis.