Cette source montre pourquoi un disque système ZimaOS saturé peut donner l’impression que la migration est bloquée sans nécessairement endommager le RAID sous-jacent ou les données utilisateur. Le SSD système de 228 GB du ZimaCube a atteint 0 B disponibles après l’accumulation de données d’indexation et d’application liées à Resilio sur le disque du système d’exploitation. L’accès SMB et Finder fonctionnait toujours, mais le tableau de bord est devenu instable et la migration est d’abord restée à 5 %.
La migration a fini par avancer : 45 %, puis 49 %, avant de s’achever après plus d’une journée. L’auteur du message original a ensuite indiqué avoir également arrêté Resilio pour l’empêcher de continuer à indexer et à écrire sur le disque système. La documentation actuelle de ZimaOS recommande désormais explicitement de conserver les données AppData hors du disque système.
Le SSD système était complètement saturé
La migration des données d’applications a d’abord semblé bloquée à 5 %
La lenteur de la progression ne signifiait pas que la migration était définitivement bloquée
L’utilisateur a ensuite constaté que la migration avait avancé à 45 %, puis à 49 % pendant la nuit. Quelques mois plus tard, il a confirmé qu’elle s’était finalement achevée, probablement après plus d’une journée.
Les consignes actuelles d’IceWhale déconseillent explicitement de stocker les données AppData sur le disque système au point de le saturer
Les consignes actuelles sur les chemins de stockage des applications indiquent que les bases de données, les miniatures, les métadonnées et autres données AppData peuvent saturer le petit disque système et perturber le fonctionnement des mises à jour, des applications et de l’appareil lui-même.
Consultez les consignes actuelles de stockage AppData.
Arrêtez l’application qui continue de saturer le disque
Libérer quelques gigaoctets ne sert à rien si Resilio, un modèle LLM, le cache Immich ou un autre conteneur les occupe immédiatement à nouveau. Identifiez l’application qui consomme le stockage système et arrêtez-la avant de relancer la migration.
Libérez suffisamment d’espace avant de relancer la migration
Une migration nécessite de l’espace pour les bases de données, les données temporaires, les journaux et les opérations des applications. Supprimez ou déplacez uniquement les données que vous avez identifiées avec certitude ; ne lancez pas de nettoyage général à la racine sur des répertoires système inconnus.
Utilisez l’outil actuel de migration des données une fois le système stabilisé
ZimaOS actuel permet de déplacer les images Docker, les données des applications Docker et les bases de données utilisateur gérées entre différents espaces de stockage via Paramètres > Migration des données.
Consultez le flux de migration des données actuel.
Un très grand nombre de petits fichiers peut ralentir l’opération au-delà de ce que leur taille totale laisse supposer
Les bases de données d’index, les miniatures et les répertoires de métadonnées peuvent nécessiter beaucoup plus d’opérations du système de fichiers par gigaoctet que les gros fichiers multimédias.
Ne déplacez pas manuellement AppData en cours d’utilisation pendant une migration
Un participant a ensuite déplacé manuellement un dossier AppData de LLM alors que la migration était déjà bloquée. Cela peut entraîner un désaccord entre le chemin configuré pour l’application, l’état de la migration dans ZimaOS et l’emplacement réel dans le système de fichiers.
La source a également signalé un problème distinct lié aux noms de fichiers dans Resilio
Des mois plus tard, timothy a indiqué que Resilio avait renommé des fichiers contenant des caractères non pris en charge, les rendant apparemment manquants dans ZimaOS. Il a expressément rectifié ses soupçons initiaux selon lesquels ZimaOS avait perdu ces fichiers.
Un tableau de bord défaillant ne signifie pas que le pool de stockage est perdu
La source pouvait toujours utiliser SMB et Finder, tandis que la session du tableau de bord était fermée et que l’interface de migration se comportait étrangement. Cette distinction est importante : un disque système plein peut perturber les services du plan de contrôle alors que la grappe de données, distincte, reste montée et lisible.
Conservez ces éléments de preuve avant toute opération destructive sur le RAID ou toute réinstallation.
Évaluez l’état du disque système avant de lancer une autre migration
Vérifiez quels répertoires occupent le disque système, identifiez l’application qui les utilise et arrêtez le processus d’écriture. Si l’application peut être supprimée puis recréée sans risque, supprimez ses caches/données d’image jetables à l’aide des commandes prévues à cet effet, plutôt que d’effacer des répertoires au hasard.
Une fois que vous disposez d’une marge d’espace suffisante, ne redémarrez que le service/l’application concerné, si nécessaire, et vérifiez que l’espace libre reste stable avant la migration.
La migration actuelle est une opération contrôlée en plein écran
La documentation actuelle d’IceWhale indique que les autres opérations sont indisponibles pendant la migration des données. Prévoyez une interruption pour les applications dont les données sont déplacées, évitez les déplacements manuels simultanés et attendez que la migration indique clairement qu’elle est terminée ou qu’une erreur s’est produite avant de modifier les mêmes dossiers.
La réinstallation est une solution de dernier recours, pas la première réponse à 0 B d’espace libre
Si les données utilisateur et le stockage sont intacts, libérer de l’espace système et terminer la migration d’AppData peut remettre le système en état sans reconstruire le NAS. Si une réinstallation s’avère nécessaire, sauvegardez d’abord les données des applications, les métadonnées du stockage et les fichiers essentiels, puis suivez les instructions de récupération/réinstallation à jour.
FAQ sur le disque système plein
La migration de la source a-t-elle fini par aboutir ?
Oui. L’auteur du message initial a ensuite indiqué que l’opération s’était terminée après plus d’une journée.
Une barre de progression de migration bloquée à 5 % prouve-t-elle que les données sont perdues ?
Non. Dans la source, la migration a ensuite progressé, tandis que SMB et le RAID sont restés accessibles.
Que doivent faire en premier les utilisateurs actuels lorsque le disque système de ZimaOS est plein ?
Arrêtez l’application qui écrit encore, libérez de l’espace en toute sécurité, puis utilisez les commandes actuelles de migration des données/AppData plutôt que de supprimer des fichiers système inconnus.
