Es war drei Uhr morgens an einem Dienstag, als mein Telefon klingelte. Ein Kunde, ein mittelständischer E-Commerce-Betreiber aus München, war panisch. Seine gesamte Datenbank war im Read-Only-Modus, die Webserver quittierten jeden Dienst und die Backups der letzten Nacht waren nur null Byte groß. Der Admin hatte am Vorabend noch schnell ein Checking Disk Space In Linux durchgeführt und gesehen, dass angeblich noch 15 Prozent Platz frei waren. Er fühlte sich sicher. Was er nicht wusste: Ein Amok laufender Log-Prozess fraß pro Minute 200 Megabyte, und die Inodes waren bereits bei 99 Prozent Auslastung. Dieser Fehler kostete das Unternehmen an diesem Vormittag schätzungsweise 40.000 Euro an entgangenen Umsätzen, nur weil jemand die oberflächlichen Zahlen eines Standard-Befehls falsch interpretierte. Ich habe solche Szenarien in den letzten fünfzehn Jahren bei Dutzenden Firmen gesehen. Die Leute vertrauen auf Tools, die sie nicht verstehen, und wundern sich, wenn das System trotzdem gegen die Wand fährt.
Das blinde Vertrauen in df und der Irrtum der 100 Prozent
Der klassische Fehler, den fast jeder macht, ist der blinde Glaube an den Befehl df -h. Man tippt es ein, sieht eine Zeile, die besagt, dass die Partition zu 85 Prozent gefüllt ist, und denkt, man hätte noch Zeit. In der Praxis ist das oft ein Trugschluss. Linux reserviert standardmäßig 5 Prozent des Speicherplatzes für den Root-User. Wenn Ihre Partition also laut Anzeige bei 95 Prozent steht, ist sie für normale Anwendungen und Dienste effektiv voll.
Ein Dienst wie MySQL oder PostgreSQL wird den Betrieb einstellen, weil er keine Daten mehr schreiben kann, obwohl Ihr Monitor-Tool vielleicht noch keine 100-Prozent-Warnung ausgibt. Ich habe Administratoren erlebt, die Stunden damit verbrachten, nach Fehlern in der Applikationslogik zu suchen, während das Problem schlicht ein blockiertes Dateisystem war. Wer beim Checking Disk Space In Linux nur auf die Prozentanzeige starrt, übersieht die Reservierung des Systems. Diese 5 Prozent sind kein Puffer für Sie, sondern eine Lebensversicherung für den Kernel, damit dieser überhaupt noch booten oder Logs schreiben kann, wenn alles andere brennt. Wenn Sie diese Reservierung nicht manuell mit tune2fs angepasst haben, was bei riesigen Terabyte-Platten durchaus Sinn ergibt, verlieren Sie massiv nutzbaren Raum oder wiegen sich in falscher Sicherheit.
Checking Disk Space In Linux scheitert oft an unsichtbaren Inodes
Das ist der Endgegner für jeden Linux-Neuling. Stellen Sie sich vor, Sie haben eine 1-Terabyte-Festplatte und df zeigt Ihnen an, dass noch 800 Gigabyte frei sind. Trotzdem erhalten Sie die Fehlermeldung "No space left on device". Das klingt unlogisch, ist aber bittere Realität, wenn Ihr System Millionen von winzigen Dateien erstellt hat – zum Beispiel Session-Files von PHP oder kleine Cache-Dateien.
Jedes Dateisystem hat eine begrenzte Anzahl an Inodes (Index-Knoten). Wenn diese aufgebraucht sind, können Sie keine einzige neue Datei mehr anlegen, völlig egal, wie viele Gigabyte an physischem Platz noch vorhanden sind. In meiner Zeit als System-Auditor war das die Ursache für etwa jeden dritten ungeplanten Stillstand. Die Leute prüfen den Speicherplatz, aber sie prüfen fast nie die Inode-Auslastung.
Warum das Inode-Limit Ihr System heimlich killt
Es gibt keinen Automatismus, der Inodes dynamisch nachschiebt. Wenn das Dateisystem bei der Erstellung (Formatierung) mit einer bestimmten Anzahl an Inodes konfiguriert wurde, ist das Gesetz. Werden viele kleine Dateien erzeugt, ist das Limit erreicht, bevor die Festplatte auch nur ansatzweise voll ist. Ein typischer Vorher/Nachher-Vergleich verdeutlicht das Problem:
Früher sah der Prozess so aus: Der Admin merkt, dass der Mailserver keine Mails mehr annimmt. Er führt ein Checking Disk Space In Linux mit dem Standardbefehl aus und sieht 40 Prozent freien Platz. Er startet den Dienst neu, prüft die Config, verzweifelt an der Firewall und sucht den Fehler im Netzwerk. Nach zwei Stunden Totalausfall kommt jemand auf die Idee, df -i einzugeben und sieht: 100 Prozent Inodes belegt.
Heute sieht der richtige Ansatz so aus: Bei jedem Monitoring-Check wird sowohl die Kapazität in Gigabyte als auch die Inode-Anzahl überwacht. Sobald die Inodes über 80 Prozent steigen, wird sofort ein Script getriggert, das alte Session-Files oder temporäre Verzeichnisse aufräumt, bevor der Dienst quittiert. Der Unterschied liegt in der Vermeidung von zwei Stunden Rätselraten. Wer nur Gigabyte zählt, hat Linux nicht verstanden.
Der Mythos der gelöschten Datei und die Geisterdaten
Hier stolpern selbst erfahrene Leute drüber. Sie stellen fest, dass die Platte voll ist. Sie finden mit du -sh /* eine riesige Logdatei, sagen wir 50 Gigabyte groß. Sie führen ein beherztes rm /var/log/monster.log aus. Doch die Anzeige von df bewegt sich kein Stück. Der Platz wird nicht frei.
Warum passiert das? Unter Linux ist eine Datei erst dann wirklich gelöscht, wenn der letzte Prozess, der sie geöffnet hat, den File-Handle schließt. Wenn ein Apache-Webserver oder eine Java-Applikation diese 50-Gigabyte-Datei noch offen hält, während Sie sie löschen, wird der Verzeichniseintrag entfernt, aber der Speicherplatz bleibt belegt. Er ist für das System quasi "unsichtbar" reserviert.
Ich habe schon Admins gesehen, die den gesamten Server neu formatiert haben, weil sie dachten, die Hardware wäre defekt oder das Dateisystem korrupt, nur weil sie nicht wussten, wie man nach offenen File-Handles sucht. Die Lösung ist hier nicht das Löschen, sondern das Leeren der Datei mit > /var/log/monster.log oder das Signalisieren des Prozesses, die Datei neu zu laden. Wenn Sie bereits gelöscht haben, hilft oft nur noch das Neustarten des betroffenen Dienstes oder im schlimmsten Fall des ganzen Systems, um die "Geisterdaten" endlich loszuwerden.
Mount-Points und die Falle der überlagerten Verzeichnisse
Ein weiterer Klassiker: Sie mounten eine neue Festplatte nach /mnt/data. Alles läuft prima. Nach drei Monaten ist die Root-Partition plötzlich voll, obwohl alle großen Daten auf /mnt/data liegen sollten. Was ist passiert?
Wahrscheinlich ist der Mount-Point irgendwann beim Booten fehlgeschlagen oder wurde unabsichtlich ausgehängt. Die Applikation hat aber munter weiter in das Verzeichnis /mnt/data geschrieben. Da die Festplatte nicht gemountet war, landeten die Daten auf der Root-Partition im zugrundeliegenden Ordner. Wenn Sie die Festplatte dann wieder mounten, liegen die alten Daten darunter versteckt. Sie belegen Platz, aber kein du oder find wird sie Ihnen anzeigen, solange der Mount aktiv ist.
In meiner Praxis ist das oft bei Backup-Servern passiert. Das externe Storage war kurz weg, das Backup-Script hat den lokalen Ordner vollgeschrieben, und am nächsten Tag war der Server tot. Um das zu finden, müssen Sie das Dateisystem an einer anderen Stelle temporär einhängen (bind-mount), um "unter" den Mount-Point zu schauen. Das spart Ihnen tagelanges Suchen nach verschwundenen Gigabytes.
Die Performance-Falle beim Scannen riesiger Verzeichnisse
Wer den Speicherplatz prüft, nutzt oft du. Das ist okay für kleine Verzeichnisse. Wenn Sie das jedoch auf einem Fileserver mit zehn Millionen kleinen Dateien oder auf einem Storage-System mit langsamen mechanischen Festplatten machen, legen Sie den Server lahm.
Der Befehl du muss jede einzelne Datei "staten", also die Metadaten vom Kernel abfragen. Bei hoher Last führt das zu massivem I/O-Wait. Ich habe erlebt, wie ein automatisierter Cronjob, der stündlich den Platzverbrauch in den User-Verzeichnissen ermitteln sollte, die Datenbankperformance so weit in den Keller zog, dass die Web-Applikation unbenutzbar wurde.
Man darf nicht vergessen, dass Tools zur Platzprüfung selbst Ressourcen fressen. Wenn das System ohnehin schon unter Druck steht, ist ein rekursives du auf Root-Ebene oft der letzte Stoß in den Abgrund. Verwenden Sie stattdessen moderne Alternativen wie ncdu (interaktiv) oder nutzen Sie Quotas auf Dateisystem-Ebene. Quotas haben den Vorteil, dass das System den Platzverbrauch bereits in Echtzeit mitloggt und Sie nicht erst die ganze Platte scannen müssen, um zu wissen, wer den Platz frisst. Das kostet zwar ein wenig CPU beim Schreiben, spart Ihnen aber den tödlichen Full-Scan, wenn es brennt.
Warum "Reserved Blocks" Ihre Rettung oder Ihr Ruin sind
Wir müssen über die reserved blocks reden. Auf einem Standard-Ext4-System sind 5 Prozent für den User root reserviert. Bei einer modernen 16-Terabyte-Festplatte sind das stolze 800 Gigabyte, die einfach so "weg" sind. Viele Admins denken, sie müssten das auf 0 setzen, um Geld zu sparen.
Das ist riskant. Diese Reservierung verhindert die Fragmentierung des Dateisystems und sorgt dafür, dass systemkritische Dienste wie syslogd oder sshd auch dann noch schreiben können, wenn ein User die Platte mit Müll geflutet hat. Wenn Sie die Reservierung auf 0 setzen, kann ein einziger voller User-Ordner dazu führen, dass Sie sich nicht einmal mehr per SSH einloggen können, um das Problem zu beheben, weil kein temporäres File mehr für die Session angelegt werden kann.
Ein kluger Mittelweg, den ich immer empfehle: Setzen Sie die Reservierung bei großen Daten-Partitionen auf 1 Prozent oder einen festen Wert von ein paar Gigabyte. Aber lassen Sie sie auf der Root-Partition niemals bei 0. Es ist der Unterschied zwischen einem schnellen Fix über die Konsole und dem Booten eines Rettungssystems im Rechenzentrum, was Sie Stunden an Zeit und Hunderte Euro an Technikergebühren kosten kann.
Der Realitätscheck: Was Sie wirklich tun müssen
Am Ende des Tages ist Speicherplatzmanagement in Linux keine Aufgabe, die man erledigt, wenn die Warnlampe leuchtet. Wenn Sie erst dann reagieren, haben Sie bereits verloren. In der echten Welt gibt es keine perfekte Automatisierung, die alles für Sie regelt. Festplatten werden voll, SSDs sterben durch zu viele Schreibzyklen bei vollem Füllstand und Log-Rotationen versagen.
Erfolgreiches Arbeiten in diesem Bereich erfordert eine paranoide Grundeinstellung. Sie müssen davon ausgehen, dass jede Anzeige lügt oder zumindest nur die halbe Wahrheit sagt. Ein Monitoring, das nur auf df basiert, ist wertlos. Sie brauchen Metriken für Inodes, Sie müssen wissen, welche Prozesse gelöschte Dateien offen halten, und Sie müssen verstehen, wie Ihr spezifisches Dateisystem (XFS, Ext4, Btrfs) mit Reservierungen umgeht.
Es gibt keine Abkürzung. Wer billige Cloud-Instanzen mit winzigen Festplatten kauft und darauf hofft, dass es schon gut geht, wird nachts um drei geweckt werden. Die Realität ist: Speicherplatz ist billig, aber die Zeit, die Sie für das Debuggen eines korrupten Dateisystems nach einem Full-Disk-Event brauchen, ist extrem teuer. Setzen Sie auf Monitoring, das Trends erkennt, statt nur Schwellenwerte zu prüfen. Wenn Ihr Speicherplatz über drei Tage hinweg linear sinkt, ist das ein Problem – auch wenn noch 40 Prozent frei sind. Das ist die einzige Strategie, die in der harten Praxis wirklich Bestand hat.
