“Built-in storage almost full” is a symptom, not a single ZimaOS bug. This source thread exposed at least three different causes: a Backup task whose USB destination disappeared and was effectively recreated under local /DATA, samoczynnie rosnący dziennik JSON Dockera, który zwiększył się do 519 GB, oraz inny system, w którym komunikat „Pamięć wbudowana jest prawie pełna” jest objawem, a nie pojedynczym błędem ZimaOS. Ten wątek źródłowy ujawnił co najmniej trzy różne przyczyny: zadanie tworzenia kopii zapasowej, którego miejsce docelowe na USB zniknęło i zostało w praktyce odtworzone w pamięci lokalnej /DATA/.media zajmował 409 GB.
Najbezpieczniej jest najpierw wykonać pomiary, zidentyfikować usługę zapisującą dane, zatrzymać proces zapisujący, a następnie usunąć wyłącznie potwierdzone dane. Nie usuwaj rekursywnie katalogów /DATA/.docker, .media ani AppData tylko dlatego, że są duże.
/DATA mimo że jego duża pula danych nadal miała do dyspozycji wiele terabajtów.Migracja danych aplikacji nie gwarantuje, że wszystkie przyszłe zapisy opuszczą /DATA
Użyj kontroli du w trybie tylko do odczytu, aby znaleźć największy katalog
Użytkownik źródłowy udostępnił:
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hrNie modyfikuje to plików. Powtórz polecenie dla podejrzanego katalogu, aby zawęzić wyszukiwanie największego poddrzewa.
Odłączone miejsce docelowe kopii zapasowej było pierwszą potwierdzoną przyczyną
Cobblerkid odkrył, że zadanie tworzenia kopii zapasowej oczekiwało zewnętrznego dysku USB. Po odłączeniu dysku struktura kopii zapasowej została odtworzona w /DATA a zaplanowane zadanie nadal zapisywało dane, aż zapełniła się pamięć lokalna.
Zima-Jerry zgodził się, że wyglądało to na problem, i przekazał sprawę wewnętrznie. To oznacza, że nie jest to już tylko teoria społeczności.
Inny użytkownik znalazł 519-gigabajtowy dziennik JSON kontenera
Drugi uczestnik sprawdził katalog jednego kontenera Dockera i znalazł *-json.log plik o rozmiarze około 519 GB, przypisany do kontenera Home Assistant.
Użytkownik usunął kontener i odzyskał miejsce. Nie należy uogólniać tego do zalecenia „ręcznie usuń logi Dockera”; najpierw zidentyfikuj kontener generujący nadmiarowe dane, sprawdź jego logi i napraw powtarzający się błąd, który je tworzy.
W trzecim systemie 409 GB znajdowało się w /DATA/.media
Inny użytkownik opublikował zestawienie rozmiarów, w którym zwykłe AppData zajmowały około 225 GB, .docker tylko 3,5 GB, ale .media zajmował 409 GB. To pokazuje, dlaczego jedno polecenie czyszczenia nie może rozwiązać każdego zgłoszenia „dysk pełny”.
Bieżący ZimaOS udostępnia więcej opcji kontroli pamięci aplikacji i pamięci podręcznej
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.
Aktualna dokumentacja IceWhale podaje, że w Ustawienia → Aplikacje wyświetlana jest lokalizacja danych aplikacji oraz dostępne jest czyszczenie pamięci podręcznej i sprawdzanie wykorzystania miejsca przez poszczególne aplikacje. Przechowywanie danych AppData na głównej macierzy pamięci masowej zmniejsza obciążenie małego dysku systemowego.
Użyj aktualnych ustawień pamięci aplikacji ZimaOS przed próbą czyszczenia z poziomu powłoki.
- Bezpieczniejsza kolejność odzyskiwania
- zatrzymaj zadanie/aplikację, która nadal generuje dane;
/DATAzmierz - tylko do odczytu;
- zidentyfikuj dokładny plik/folder i jego właściciela;
- twórz kopie zapasowe ważnych danych AppData/konfiguracji;
- w miarę możliwości korzystaj z obsługiwanych ustawień aplikacji/pamięci podręcznej;
- usuwaj tylko dane jednorazowe lub zweryfikowane jako błędne;
docker image prune nie rozwiązuje każdego problemu z miejscem zajmowanym przez Dockera
W źródle raller1028 wspomniał docker image prune -a jako sposobu usuwania obrazów nieużywanych przez kontenery. Może to odzyskać miejsce zajmowane przez nieużywane warstwy obrazów, ale nie rozwiąże problemu aktywnego logu JSON kontenera o rozmiarze 519 GB, niekontrolowanie rozrastającego się celu kopii zapasowej ani danych użytkownika w .media.
Najpierw użyj skanowania rozmiaru, aby zidentyfikować kategorię. Polecenie czyszczenia skierowane do niewłaściwej kategorii może zwolnić niemal nic, jednocześnie stwarzając nowe ryzyko.
Ogromny dziennik JSON oznacza, że pętla błędów kontenera nadal ma znaczenie
Usunięcie problematycznego kontenera zwolniło miejsce u jednego użytkownika, ale ważniejsze pytanie długoterminowe brzmi: dlaczego aplikacja zapisała setki gigabajtów logów. Przed ponowną instalacją tego samego obciążenia sprawdź najnowsze logi pod kątem powtarzających się błędów, pętli restartów, niedostępnych urządzeń lub problemów z konfiguracją.
Jeśli odtworzony kontener natychmiast zacznie ponownie generować logi, problem z pełnym dyskiem powróci.
Traktuj .media jako pamięć zarządzaną, a nie jednorazową pamięć podręczną
409 GB /DATA/.media przykład może zawierać rzeczywiste zarządzane dane zamontowanych zasobów/plików, a nie tymczasową pamięć podręczną. Przed usunięciem czegokolwiek ustal, która pamięć masowa/udział/aplikacja jest ich właścicielem, i potwierdź, że te same pliki istnieją w innym miejscu.
FAQ: pełna pamięć wbudowana
Czy źródło dowiodło, że sama migracja AppData się nie powiodła?
Nie. Autor oryginalnego posta przeniósł zarządzane kategorie; potwierdzone zapełnienie pochodziło z odłączonego celu kopii zapasowej.
Czy bezpiecznie jest usunąć cały katalog .docker?
Nie. Może zawierać aktywny stan kontenerów, logi, obrazy i zależności aplikacji.
Jaka jest najlepsza pierwsza komenda ze źródła?
Tylko do odczytu du skan rozmiaru za pomocą /DATA aby zidentyfikować faktycznie duże poddrzewo.
