« Le stockage intégré est presque plein » est un symptôme, pas un bogue unique de ZimaOS. Cette discussion source a révélé au moins trois causes différentes : une tâche de sauvegarde dont la destination USB avait disparu et avait de fait été recréée dans le stockage local sous /DATA, un journal JSON Docker incontrôlé qui avait atteint 519 Go, et un autre système où /DATA/.media occupait 409 Go.
La réponse la plus sûre consiste d’abord à mesurer, à identifier le service propriétaire, à arrêter le processus d’écriture, puis à nettoyer uniquement les données confirmées. Ne supprimez pas récursivement /DATA/.docker, .media ou AppData simplement parce qu’ils sont volumineux.
/DATA même si son vaste pool de données disposait encore de plusieurs téraoctets libres.La migration des données d’application ne garantit pas que toutes les écritures futures quitteront /DATA
Utilisez des vérifications du type « du » en lecture seule pour trouver le répertoire le plus volumineux
L’utilisateur à l’origine de la discussion a partagé :
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hrCela ne modifie aucun fichier. Répétez la commande sur un répertoire suspect pour repérer le sous-arbre le plus volumineux.
Une destination de sauvegarde déconnectée était la première cause confirmée
Cobblerkid a découvert qu’une tâche de sauvegarde attendait une clé USB externe. Après la déconnexion de celle-ci, la structure de sauvegarde a été recréée sous /DATA et la tâche planifiée a continué à écrire jusqu’à ce que le stockage local soit saturé.
Zima-Jerry a confirmé qu’il s’agissait apparemment d’un problème et l’a transmis en interne. Il ne s’agit donc plus seulement d’une théorie de la communauté.
Un autre utilisateur a trouvé un journal JSON de conteneur de 519 Go
Un deuxième participant a inspecté le répertoire d’un conteneur Docker et a trouvé un *-json.log fichier d’environ 519 Go, attribué à un conteneur Home Assistant.
L’utilisateur a supprimé le conteneur et récupéré de l’espace. N’en déduisez pas qu’il faut « supprimer manuellement les journaux Docker » ; identifiez d’abord le conteneur bruyant, inspectez ses journaux et corrigez l’erreur répétée qui les génère.
Un troisième système avait 409 Go dans /DATA/.media
Un autre utilisateur a publié une ventilation de l’espace où les données d’application normales occupaient environ 225 Go, .docker seulement 3,5 Go, mais .media occupait 409 Go. Cela montre pourquoi une seule commande de nettoyage ne peut pas résoudre tous les cas de « disque plein ».
La version actuelle de ZimaOS offre davantage de contrôle sur le stockage et le cache des applications
La documentation actuelle d’IceWhale indique que Paramètres → Applications affiche l’emplacement des données d’application ainsi que l’utilisation par application et le nettoyage du cache. Conserver les AppData sur la baie de stockage principale réduit la pression exercée sur le petit disque système.
Utilisez les commandes actuelles de gestion du stockage des applications ZimaOS avant de tenter un nettoyage depuis le shell.
Un ordre de récupération plus sûr
- arrêter la tâche ou l’application qui génère encore des données ;
- mesurer
/DATAen lecture seule ; - identifier le fichier ou dossier exact et son propriétaire ;
- sauvegarder les AppData et la configuration importantes ;
- utiliser autant que possible les commandes de contrôle prises en charge pour les applications et les caches ;
- ne supprimer que les données jetables ou dont l’erreur a été vérifiée ;
- confirmer que l’espace libre reste stable après le redémarrage.
docker image prune ne résout pas tous les problèmes d’espace de Docker
Dans la source, raller1028 a mentionné docker image prune -a comme moyen de supprimer les images non utilisées par les conteneurs. Cela peut récupérer des couches d’images inutilisées, mais ne résoudra pas le problème d’un journal JSON actif de conteneur de 519 Go, d’une destination de sauvegarde hors de contrôle ou des données utilisateur sous .media.
Utilisez l’analyse de taille pour identifier d’abord la catégorie. Une commande de nettoyage visant la mauvaise catégorie peut libérer presque aucun espace tout en créant de nouveaux risques.
Un énorme journal JSON signifie que la boucle d’erreurs du conteneur reste importante
La suppression du conteneur problématique a libéré de l’espace pour un utilisateur, mais la meilleure question à long terme est de savoir pourquoi l’application a écrit des centaines de gigaoctets de journaux. Examinez les journaux récents à la recherche d’erreurs répétées, de boucles de redémarrage, de périphériques indisponibles ou de problèmes de configuration avant de réinstaller la même charge de travail.
Si le conteneur recréé recommence immédiatement à générer des journaux, le problème de disque plein réapparaîtra.
Traitez .media comme un stockage géré, pas comme un cache jetable
Les 409 Go /DATA/.media l’exemple peut contenir de véritables données de montage ou de fichiers gérées, plutôt qu’un cache temporaire. Avant d’y supprimer quoi que ce soit, identifiez le stockage, le partage ou l’application qui en est propriétaire et vérifiez que les mêmes fichiers existent ailleurs.
FAQ : stockage intégré saturé
La source a-t-elle prouvé que la migration d’AppData elle-même avait échoué ?
Non. L’auteur de la publication originale avait migré les catégories gérées ; le remplissage confirmé provenait d’une cible de sauvegarde déconnectée.
Est-il prudent de supprimer tout le répertoire .docker ?
Non. Il peut contenir l’état actif des conteneurs, les journaux, les images et les dépendances des applications.
Quelle est la meilleure première commande à utiliser d’après la source ?
Une commande en lecture seule du analyse de taille de /DATA pour identifier le sous-arbre volumineux réel.
