”Det inbyggda lagringsutrymmet är nästan fullt” är ett symptom, inte ett enda ZimaOS-fel. Den här källtråden visade minst tre olika orsaker: en säkerhetskopieringsuppgift vars USB-destination försvann och i praktiken återskapades under det lokala /DATA, en skenande Docker JSON-logg som växte till 519 GB, och ett annat system där /DATA/.media förbrukade 409 GB.
Det säkraste är att först mäta, identifiera tjänsten som äger datan, stoppa skrivningen och sedan endast rensa bekräftade data. Ta inte bort /DATA/.docker, .media eller AppData rekursivt bara för att de är stora.
/DATA även om den stora datapoolen fortfarande hade flera terabyte ledigt utrymme.Att migrera appdata garanterar inte att alla framtida skrivningar lämnar /DATA
Använd skrivskyddade du-kontroller för att hitta den största katalogen
Källanvändaren delade:
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hrDetta ändrar inga filer. Upprepa kommandot för en misstänkt katalog för att begränsa sökningen till det största underträdet.
En frånkopplad säkerhetskopieringsdestination var den första bekräftade orsaken
Cobblerkid upptäckte att en säkerhetskopieringsuppgift förväntade sig en extern USB-enhet. Efter att enheten kopplats från återskapades säkerhetskopieringsstrukturen under /DATA och det schemalagda jobbet fortsatte att skriva tills det lokala lagringsutrymmet var fullt.
Zima-Jerry höll med om att detta verkade vara ett problem och skickade det vidare internt. Det gör detta till mer än bara en teori från communityn.
En annan användare hittade en 519 GB stor JSON-logg för en container
En annan deltagare granskade en Docker-containers katalog och hittade en *-json.log en fil på ungefär 519 GB, kopplad till en Home Assistant-container.
Användaren tog bort containern och frigjorde utrymme. Generalisera inte detta till ”ta bort Docker-loggar manuellt”; identifiera först containern som genererar mest data, granska dess loggar och åtgärda det återkommande felet som skapar loggen.
Ett tredje system hade 409 GB under /DATA/.media
En annan användare publicerade en storleksfördelning där normal AppData var cirka 225 GB, .docker bara 3,5 GB, men .media förbrukade 409 GB. Detta visar varför ett enda rensningskommando inte kan lösa alla rapporter om ”full disk”.
Aktuella ZimaOS visar fler kontroller för app- och cachelagring
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.
Aktuell dokumentation från IceWhale anger att Inställningar → Appar visar platsen för AppData samt rensning av användning/cache per app. Om du behåller AppData på huvudlagringsarrayen minskar belastningen på den lilla systemdisken.
Använd de aktuella kontrollerna för app-lagring i ZimaOS innan du försöker rensa via skalet.
- En säkrare återställningsordning
- stoppa uppgiften/appen som fortfarande genererar data;
/DATAmät - skrivskyddad;
- identifiera den exakta filen/mappen och dess ägare;
- säkerhetskopiera viktig AppData/konfiguration;
- använd appens stödda kontroller för cache där det är möjligt;
- ta endast bort förbrukningsbar eller verifierat felaktig data;
docker image prune löser inte alla Docker-relaterade utrymmesproblem
I källan nämnde raller1028 docker image prune -a som ett sätt att ta bort avbildningar som inte används av containrar. Det kan återta oanvända avbildningslager, men det löser inte en aktiv JSON-logg på 519 GB, ett skenande Backup-mål eller användardata under .media.
Använd storleksskanningen för att först identifiera kategorin. Ett rensningskommando som riktas mot fel kategori kan frigöra nästan inget utrymme samtidigt som det skapar nya risker.
En enorm JSON-logg innebär att containerns fellogg fortfarande är viktig
Att ta bort den problematiska containern frigjorde utrymme för en användare, men den viktigare långsiktiga frågan är varför programmet skrev hundratals gigabyte med loggar. Granska de senaste loggarna efter upprepade fel, omstartsloopar, otillgängliga enheter eller konfigurationsproblem innan du installerar om samma arbetsbelastning.
Om den återskapade containern omedelbart börjar generera loggar igen kommer problemet med full disk att återkomma.
Betrakta .media som hanterad lagring, inte som förbrukningsbar cache
De 409 GB /DATA/.media exemplet kan innehålla verkliga hanterade monteringspunkter/filer i stället för tillfällig cache. Innan du tar bort något där ska du identifiera vilken lagring/delning/app som äger det och bekräfta att samma filer finns någon annanstans.
Vanliga frågor om full inbyggd lagring
Visade källan att migreringen av AppData i sig misslyckades?
Nej. Den ursprungliga skribenten hade migrerat de hanterade kategorierna; den bekräftade platsbristen kom från ett frånkopplat Backup-mål.
Är det säkert att ta bort hela katalogen .docker?
Nej. Den kan innehålla aktivt containertillstånd, loggar, avbildningar och programberoenden.
Vilket är det bästa första kommandot i källan?
En skrivskyddad du storleksskanning av /DATA för att identifiera det faktiska stora underträdet.
