Beide. df fragt das Dateisystem, wie viele Blöcke belegt sind; du läuft den Verzeichnisbaum ab und addiert, was es sieht. Wenn die beiden auseinanderlaufen, hält etwas Platz fest, das keinen Namen mehr hat. So finden Sie es.
1. Die Differenz bestätigen
$ clai vergleiche was df für / meldet mit dem was du dort tatsächlich findet→ df -h / && du -shx / 2>/dev/nullFilesystem Size Used Avail Use% Mounted on/dev/nvme1n1p2 915G 871G 44G 96% /348G /871 GB belegt, 348 GB gefunden. Diese Lücke ist das ganze Problem. -x hält du davon ab, in andere eingehängte Dateisysteme abzuwandern und die eigene Zahl aufzublähen.
2. Erst Inodes prüfen, dann Bytes jagen
$ clai prüfe ob dem Dateisystem die Inodes ausgegangen sind statt des Platzes→ df -i /Filesystem Inodes IUsed IFree IUse% Mounted on/dev/nvme1n1p2 124960768 3634368 121326400 3% /Steht IUse% bei 100%, Use% aber nicht, haben Sie Millionen winziger Dateien und keinen freien Inode mehr. Das ist ein anderes Problem: Platz ist da, aber das Dateisystem kann keine weitere Datei mehr eintragen.
3. Gelöschte, aber noch offene Dateien finden
$ clai zeig Dateien die gelöscht wurden aber noch von einem Prozess offen gehalten werden→ sudo lsof +L1COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAMEpython3 23435 app 3u REG 259,2 1000000000 0 41231 /var/log/app/debug.log (deleted)NLINK 0 ist die Signatur: Kein Verzeichniseintrag zeigt mehr auf diese Datei, du sieht sie also nicht, die Blöcke bleiben aber belegt, bis der letzte Dateideskriptor schließt. Meist ist es ein Log, das jemand gelöscht hat, ohne den schreibenden Dienst neu zu starten.
4. Den Platz zurückholen
$ clai starte den Dienst neu der diese gelöschte Datei festhält→ sudo systemctl restart app.serviceDer Neustart schließt den Deskriptor und der Kernel gibt die Blöcke sofort frei. df fällt im selben Moment – ohne Aushängen, ohne Reboot.
5. Wenn ein Neustart gerade nicht geht
$ clai leere die gelöschte Datei die pid 23435 auf fd 3 noch hält→ sudo truncate -s 0 /proc/23435/fd/3Der Schreibzugriff über /proc/<pid>/fd/<n> leert die Datei, in die der Prozess weiterschreibt, ohne ihn zu beenden. Der Prozess behält seinen Deskriptor und loggt weiter; Sie bekommen den Platz sofort.
6. Der andere Klassiker: ein Mountpoint verdeckt Dateien
$ clai prüfe ob etwas über ein Verzeichnis gemountet ist in dem noch Dateien liegen→ sudo mount --bind / /mnt/root && du -shx /mnt/root/var14G /mnt/root/varWurde nach /var/data geschrieben, bevor dort eine Platte eingehängt wurde, liegen die Dateien weiter im Root-Dateisystem – und belegen Platz, den durch den Mount niemand sieht. Ein Bind-Mount von / legt sie offen.
Stolperfallen
duals root ausführen. Als normaler Nutzer überspringt es stillschweigend unlesbare Verzeichnisse, und Sie suchen ein Phantom, wo eigentlich Rechte das Problem sind.lsof +L1braucht Privilegien, um fremde Deskriptoren zu sehen. Ohnesudobekommen Sie eine kurze, trügerisch saubere Liste.- Ein aktives Log nicht erneut löschen. Genau das hat die Situation erzeugt. Bei laufenden Logs
truncate -s 0nehmen oder logrotate mitcopytruncatekonfigurieren.
Verwandte Fragen
Warum kommt der Platz nach rm nicht zurück? Unter Unix entfernt Unlink den Namen, nicht die Daten. Die Blöcke werden frei, wenn der letzte offene Deskriptor schließt – bei einem laufenden Dienst also nie, bis er neu startet.
du und df weichen um ein paar Prozent ab, ist das schlimm? Nein. Das sind reservierte Blöcke (bei ext4 standardmäßig 5% für root) plus Metadaten. Nur große Lücken sind eine Untersuchung wert.
Geht das auch ohne lsof? Ja: sudo ls -l /proc/*/fd 2>/dev/null | grep deleted zeigt dasselbe über die Prozesstabelle.
Siehe auch
- „Wer frisst gerade meine CPU?“ – Systemüberwachung in Alltagssprache
- Alte Logs und Backups mit einem Satz aufräumen
- Dateien älter als 30 Tage in Linux sicher löschen
Schluss mit dem Nachschlagen von lsof-Flags um 3 Uhr nachts – beschreiben Sie das Problem, CliAI schreibt den Befehl. In einer Zeile installieren.