Cette source montre pourquoi un disque système ZimaOS plein peut donner l’impression que la migration est bloquée sans nécessairement endommager le RAID sous-jacent ni les données utilisateur. Le SSD système de 228 Go du ZimaCube affichait 0 octet disponible après l’augmentation des 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 était devenu instable et la migration est initialement restée à 5 %.
La migration a finalement progressé — 45 %, puis 49 % — avant de se terminer après plus d’une journée. L’auteur du message a ensuite indiqué avoir également empêché Resilio 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 en dehors du disque système.
Le SSD système était complètement saturé
La migration des données d’application semblait d’abord bloquée à 5 %
Une progression lente ne signifiait pas que la migration était définitivement bloquée
L’utilisateur a ensuite vu la migration progresser à 45 %, puis à 49 % pendant la nuit. Plusieurs mois plus tard, il a confirmé qu’elle s’était finalement terminée, probablement après plus d’une journée.
Les recommandations actuelles d’IceWhale déconseillent explicitement de remplir le disque système avec AppData
Les recommandations actuelles relatives aux chemins de stockage des applications indiquent que les bases de données d’application, les miniatures, les métadonnées et autres données AppData peuvent remplir le petit disque système et provoquer un fonctionnement anormal des mises à jour, des applications et de l’appareil lui-même.
Consultez les recommandations actuelles sur le stockage des données AppData.
Arrêtez l’application qui continue de remplir le disque
Libérer quelques gigaoctets ne sert à rien si Resilio, un modèle de LLM, le cache d’Immich ou un autre conteneur les réécrit immédiatement. Identifiez l’application qui consomme l’espace système et arrêtez-la avant de relancer la migration.
Libérez une marge de manœuvre avant de relancer la migration
Un processus de migration a besoin d’espace pour les bases de données, l’état temporaire, les journaux et les opérations des applications. Supprimez ou déplacez uniquement les données que vous avez identifiées avec certitude ; n’effectuez pas de nettoyage généralisé à la racine sur des répertoires système inconnus.
Utilisez l’outil actuel de migration des données une fois le système stabilisé
La version actuelle de ZimaOS peut déplacer les images Docker, les données d’application Docker et les bases de données utilisateur gérées entre les espaces de stockage via Paramètres > Migration des données.
Consultez le processus actuel de migration des données.
Un très grand nombre de petits fichiers peut être plus lent à transférer que leur taille totale ne le laisse penser
Les bases de données d’indexation, les miniatures et les répertoires de métadonnées peuvent nécessiter bien plus d’opérations du système de fichiers par gigaoctet que les gros fichiers multimédias.
Ne déplacez pas manuellement les données AppData actives pendant une migration
Un participant ultérieur a déplacé manuellement un dossier AppData de LLM alors que la migration était déjà bloquée. Cela peut provoquer une divergence entre le chemin configuré de l’application, l’état de migration de ZimaOS et l’emplacement réel dans le système de fichiers.
La source signalait également un problème distinct de noms de fichiers avec Resilio
Plusieurs mois plus tard, timothy a indiqué que Resilio avait renommé des fichiers contenant des caractères non pris en charge, les faisant apparaître comme manquants dans ZimaOS. Il a explicitement corrigé son soupçon initial selon lequel ZimaOS aurait 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 alors que le tableau de bord se déconnectait et que l’interface de migration se comportait de manière étrange. Cette distinction est importante : un disque système plein peut perturber les services du plan de contrôle tandis que la baie de données séparée reste montée et lisible.
Conservez ces éléments avant d’entreprendre des opérations destructrices sur le RAID ou de réinstaller le système.
Analysez le disque système avant de lancer une nouvelle migration
Vérifiez quels répertoires consomment l’espace du disque système, identifiez l’application responsable et arrêtez le processus d’écriture. Si l’application peut être supprimée et recréée sans risque, supprimez ses données de cache ou d’image non essentielles via les contrôles pris en charge plutôt que d’effacer des répertoires au hasard.
Une fois une marge de manœuvre disponible, redémarrez uniquement le service ou 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 l’exécution de 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 laissez la migration atteindre un état clair de réussite ou d’erreur avant de modifier les mêmes dossiers.
La réinstallation est un dernier recours, pas la première réaction face à 0 octet libre
Si les données utilisateur et le stockage sont intacts, libérer de l’espace système et terminer la migration des données AppData peut permettre de récupérer le système sans reconstruire le NAS. Si une réinstallation devient nécessaire, sauvegardez d’abord les données des applications, les métadonnées du stockage et les fichiers essentiels, puis suivez les recommandations actuelles de récupération et de réinstallation.
FAQ sur un disque système plein
La migration de la source s’est-elle finalement terminée ?
Oui. L’auteur du message a ensuite indiqué qu’elle 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 restaient accessibles.
Que doivent faire en premier les utilisateurs actuels lorsque ZimaOS-HD est plein ?
Arrêter l’application qui continue d’écrire, libérer de l’espace en toute sécurité, puis utiliser les contrôles actuels de migration des données et d’AppData plutôt que de supprimer des fichiers système inconnus.
