„Integrierter Speicher fast voll“ ist ein Symptom und kein einzelner ZimaOS-Fehler. Dieser Quellthread zeigte mindestens drei verschiedene Ursachen: eine Backup-Aufgabe, deren USB-Ziel verschwunden war und effektiv unter dem lokalen Speicher neu erstellt wurde. /DATA, ein außer Kontrolle geratenes Docker-JSON-Log, das auf 519 GB anwuchs, sowie ein anderes System, bei dem /DATA/.media belegte 409 GB.
Am sichersten ist es, zuerst zu messen, den zuständigen Dienst zu ermitteln, den Schreibvorgang zu stoppen und anschließend nur die bestätigten Daten zu bereinigen. Löschen Sie nicht /DATA/.docker, .media oder AppData rekursiv, nur weil diese Verzeichnisse groß sind.
/DATA obwohl sein großer Datenpool noch über mehrere Terabyte freien Speicher verfügte.Die Migration von App-Daten garantiert nicht, dass alle zukünftigen Schreibvorgänge /DATA verlassen
Verwenden Sie schreibgeschützte du-Prüfungen, um das größte Verzeichnis zu finden
Der Nutzer der ursprünglichen Quelle teilte Folgendes mit:
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hrDies ändert keine Dateien. Wiederholen Sie den Befehl für ein verdächtiges Verzeichnis, um den größten Unterbaum einzugrenzen.
Ein getrenntes Backup-Ziel war die erste bestätigte Ursache
Cobblerkid stellte fest, dass eine Backup-Aufgabe ein externes USB-Laufwerk erwartete. Nachdem das Laufwerk getrennt worden war, wurde die Backup-Struktur unter /DATA und der geplante Auftrag schrieb weiter, bis der lokale Speicher voll war.
Zima-Jerry stimmte zu, dass dies wie ein Problem aussah, und leitete es intern weiter. Damit handelt es sich um mehr als nur eine Theorie aus der Community.
Ein anderer Nutzer fand ein 519 GB großes Container-JSON-Log
Ein zweiter Teilnehmer untersuchte das Verzeichnis eines Docker-Containers und fand eine *-json.log eine ungefähr 519 GB große Datei, die einem Home-Assistant-Container zugeschrieben wurde.
Der Nutzer entfernte den Container und gewann Speicherplatz zurück. Verallgemeinern Sie daraus nicht, dass „Docker-Logs manuell gelöscht“ werden sollten. Ermitteln Sie zunächst den Container mit den ungewöhnlichen Aktivitäten, prüfen Sie dessen Logs und beheben Sie den wiederholten Fehler, der das Log erzeugt.
Ein drittes System hatte 409 GB unter /DATA/.media
Ein anderer Nutzer veröffentlichte eine Größenaufstellung, in der die normalen AppData etwa 225 GB belegten, .docker nur 3,5 GB, aber .media belegte 409 GB. Das zeigt, warum ein einziger Bereinigungsbefehl nicht jedes Problem mit einer „vollen Festplatte“ lösen kann.
Die aktuelle Version von ZimaOS bietet mehr Kontrolle über App-Speicher und Cache.
Current IceWhale documentation says Settings → Apps shows the App data location and per-app usage/cache cleanup. Keeping AppData on the main storage array reduces pressure on the small system drive.
Die aktuelle Dokumentation von IceWhale besagt, dass unter „Einstellungen → Apps“ der Speicherort der App-Daten sowie die appbezogene Nutzung und Cache-Bereinigung angezeigt werden. Wenn AppData auf dem Hauptspeicher-Array verbleibt, wird der Druck auf das kleine Systemlaufwerk verringert.
Verwenden Sie die aktuellen ZimaOS-Steuerungen für den App-Speicher, bevor Sie eine Bereinigung über die Shell versuchen.
- Eine sicherere Wiederherstellungsreihenfolge
- stoppen Sie die Aufgabe bzw. App, die weiterhin Daten erzeugt;
/DATAmessen - schreibgeschützt;
- identifizieren Sie die genaue Datei bzw. den genauen Ordner und den Besitzer;
- sichern Sie wichtige AppData-/Konfigurationsdaten;
- verwenden Sie nach Möglichkeit unterstützte App-/Cache-Steuerungen;
- entfernen Sie nur entbehrliche oder nachweislich fehlerhafte Daten;
docker image prune behebt nicht jedes Docker-Speicherproblem
In der Quelle erwähnte raller1028 docker image prune -a als Möglichkeit, von Containern nicht verwendete Images zu entfernen. Dadurch können ungenutzte Image-Ebenen zurückgewonnen werden, aber ein 519-GB-aktives Container-JSON-Protokoll, ein außer Kontrolle geratenes Backup-Ziel oder Benutzerdaten unter .media.
Verwenden Sie die Größenprüfung, um zuerst die Kategorie zu identifizieren. Ein Bereinigungsbefehl für die falsche Kategorie kann kaum Speicherplatz freigeben und gleichzeitig neue Risiken schaffen.
Ein riesiges JSON-Protokoll bedeutet, dass die Fehlerschleife des Containers weiterhin relevant ist
Das Entfernen des problematischen Containers gab einem Benutzer Speicherplatz frei, aber die wichtigere langfristige Frage ist, warum die Anwendung Hunderte Gigabyte an Protokollen geschrieben hat. Prüfen Sie vor der erneuten Installation derselben Arbeitslast die aktuellen Protokolle auf wiederholte Fehler, Neustartschleifen, nicht verfügbare Geräte oder Konfigurationsprobleme.
Wenn der neu erstellte Container sofort wieder Protokolle erzeugt, kehrt der Speicherplatzmangel zurück.
.media als verwalteten Speicher behandeln, nicht als entbehrlichen Cache
Die 409 GB /DATA/.media Das Beispiel kann tatsächlich verwaltete Mount-/Dateidaten statt eines temporären Caches enthalten. Identifizieren Sie vor dem Löschen, welcher Speicher, welche Freigabe oder welche App dafür zuständig ist, und bestätigen Sie, dass sich dieselben Dateien auch an anderer Stelle befinden.
FAQ: Integrierter Speicher voll
Hat die Quelle bewiesen, dass die AppData-Migration selbst fehlgeschlagen ist?
Nein. Der ursprüngliche Verfasser hatte die verwalteten Kategorien migriert; die bestätigte Belegung stammte von einem getrennten Backup-Ziel.
Ist es sicher, das gesamte Verzeichnis .docker zu löschen?
Nein. Es kann den aktiven Containerstatus, Protokolle, Images und Anwendungsabhängigkeiten enthalten.
Was ist der beste erste Befehl aus der Quelle?
Ein schreibgeschützter du Größenprüfung mit /DATA um den tatsächlich großen Unterbaum zu identifizieren.
