«No space left on device» diagnostizieren, obwohl df freien Platz zeigt

Ziel

Herausfinden, welche der vier Ursachen für einen Schreibfehlschlag mit ENOSPC zutrifft, und dann die richtige Ressource freigeben, statt wahllos Dateien zu löschen.

Voraussetzungen

Root- oder sudo-Zugriff auf dem betroffenen Host, die Fehlermeldung mit dem fehlgeschlagenen Pfad sowie Zugriff auf df, du, lsof oder /proc.

Schritte

1. Das Dateisystem lokalisieren: df -h /path/that/failed gibt den Mountpunkt aus; ein volles /var/log auf einer eigenen Partition sieht für die Anwendung genauso aus wie ein volles Root.
2. Bytes und Inodes getrennt prüfen: df -h und df -i (--inodes) auf diesem Mount. Ein ext4-Dateisystem wird mit einer festen, aus bytes-per-inode abgeleiteten Anzahl Inodes angelegt (mke2fs(8)); ein Verzeichnis mit Millionen winziger Dateien (Sessions, Cache-Shards, Mail-Warteschlangen) kann die Inodes erschöpfen, während die meisten Bytes noch frei sind. Steht IUse% bei 100, das Verzeichnis finden mit find /mount -xdev -type d -exec sh -c 'echo $(ls -1A "$1" | wc -l) "$1"' _ {} \; | sort -n | tail.
3. Auf gelöschte, aber noch geöffnete Dateien prüfen: unlink(2) hält fest, dass eine Datei, deren letzter Name entfernt wurde, die aber noch geöffnet ist, bis zum Schliessen des letzten Deskriptors weiter existiert. lsof +L1 oder find /proc/*/fd -lname '*(deleted)' listet sie auf; typischerweise hält ein Logging-Prozess oder eine Datenbank mit einer rotierten Datei sie offen. Diesen Prozess neu starten oder signalisieren (kill -HUP bei Daemons, die Logs neu öffnen), statt weiter zu löschen.
4. Reservierung prüfen: ext-Dateisysteme halten einen reserved-blocks-percentage (Standard 5 % laut mke2fs(8)) vor, der nur von root nutzbar ist, sodass unprivilegierte Prozesse scheitern, während df noch ein paar Prozent frei zeigt. tune2fs -m 1 senkt ihn auf Datenvolumes; auf dem Root-Dateisystem beibehalten.
5. Ist der Platz tatsächlich belegt, ihn mit du -xh --max-depth=1 /mount | sort -h finden (-x bleibt auf einem Dateisystem) und die eigene Bereinigung der jeweiligen Eigentümer (journalctl --vacuum-size, Bereinigung von Container-Images, Log-Rotation) gegenüber rm bevorzugen.
6. Ursache und Behebung festhalten; ist ein Wachstumstrend erkennbar, einen Alarm auf Inode- und Byte-Nutzung je Mount ergänzen, nicht nur auf dem Root-Dateisystem.

Erwartetes Ergebnis

Der Schreibvorgang gelingt wieder, die Ursache ist benannt (Inodes, gehaltene Datei, Reservierung oder tatsächliche Nutzung), und das Monitoring deckt die Dimension ab, die versagt hat.

Grenzen und Prüfbasis

Das beschriebene Dateisystemverhalten gilt für die ext-Familie; XFS und btrfs weisen Inodes anders zu und haben eigene Werkzeuge zur Nutzungsauswertung. Overlay-Dateisysteme von Containern und tmpfs-Mounts bringen weitere, hier nicht behandelte Grenzen mit sich (tmpfs-Grösse, Container-Quotas). Es wird keine Messung oder Feldbeobachtung behauptet.