Comment vérifier si une partition système complète affecte les applications NAS

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How to Check Whether a Full System Partition Is Affecting NAS Apps - Zima Store Online

Une partition système pleine peut arrêter les applications NAS même lorsque le grand pool de données dispose encore de téraoctets d’espace libre.

Les applications ont besoin d’espace local pour les journaux, bases de données, fichiers temporaires, mises à jour, couches de conteneurs, sockets et écritures de configuration. Confirmez quelle partition est pleine, associez l’erreur de l’application à une écriture échouée, identifiez le consommateur système, puis récupérez de l’espace via le composant qui en est propriétaire.

Confirmer que la partition système est la partition pleine

Vérifiez tous les systèmes de fichiers montés et cartographiez les chemins root, boot, application, conteneur et données. La première tâche est de confirmer la partition pleine exacte, car l’espace libre sur le pool de données ne peut pas satisfaire une écriture dirigée vers le système de fichiers root.

Utilisez df -h pour la capacité en blocs et df -i pour les inodes. Un chemin peut refuser de nouveaux fichiers lorsque les blocs libres et les inodes libres sont des limites distinctes et que l’une ou l’autre est épuisée.

Symptôme de l’app	Écriture probablement échouée	À vérifier
Erreur de connexion ou de base de données	Journal de base de données ou socket	Journaux de l’app et chemin de la base de données
Échec de mise à jour ou d’installation	Cache de paquets ou fichier temporaire	Partitions root et temporaires
Le conteneur ne démarre pas	Couche overlay, journal ou état	Utilisation du stockage du conteneur
Échecs de téléversement	Chemin temporaire de mise en attente	Répertoire temporaire configuré

Associer les échecs d’applications à un manque d’espace d’écriture

Consultez les journaux de l’application, de la base de données, du conteneur et du système pour des messages tels que « plus d’espace disponible », système de fichiers en lecture seule, journal échoué ou impossibilité de créer un fichier temporaire. Une application peut toujours afficher sa page web depuis la mémoire alors que les tâches en arrière-plan, téléversements et validations de base de données échouent.

Notez les horodatages et testez une écriture sans risque dans le chemin affecté. Évitez les redémarrages massifs tant que vous n’avez pas sauvegardé les preuves ; redémarrer toutes les applications peut générer plus de journaux, masquer la première erreur et modifier le service qui échoue ensuite.

Trouver les journaux, couches de conteneurs, inodes et fichiers supprimés

Mesurez les répertoires système de premier niveau, puis explorez le plus volumineux. Les consommateurs courants incluent les journaux, journaux d’applications, couches d’images, caches de compilation, vidages de crash, caches de paquets, vignettes et fichiers temporaires. Utilisez les rapports de l’application ou du gestionnaire de conteneurs avant de supprimer des répertoires de données opaques.

Si les totaux des répertoires n’expliquent pas l’utilisation du système de fichiers, vérifiez la présence de fichiers supprimés encore ouverts. Si les inodes sont pleins, localisez les répertoires contenant un grand nombre de petits fichiers de cache ou de session. Après récupération, configurez la rotation des journaux et les limites de rétention plutôt que de répéter des suppressions d’urgence.

Libérer de l’espace en toute sécurité et vérifier la récupération

Commencez par les chemins de nettoyage documentés : faites tourner ou nettoyez les journaux, supprimez les caches de paquets confirmés inutilisés, émondez uniquement les artefacts de conteneurs inutilisés et supprimez les anciens vidages de crash via leurs outils. Préservez les bases de données, volumes nommés, images actives et configurations jusqu’à disposer d’une sauvegarde vérifiée.

Revérifiez l’utilisation du système de fichiers et des inodes, puis redémarrez uniquement la chaîne de dépendance affectée et testez une écriture réelle d’application. Si la récupération échoue encore, étudiez l’ordre de démarrage des services après un redémarrage au lieu de supposer que l’espace est toujours la cause.

FAQ

Pourquoi une application échoue-t-elle alors que le pool de données NAS a de l’espace libre ?

L’application peut écrire sa base de données, ses journaux, fichiers temporaires ou état de conteneur sur la plus petite partition système. La capacité n’est pas automatiquement partagée entre les partitions.

La suppression des fichiers journaux peut-elle aggraver le problème ?

Oui. Un processus en cours peut garder un journal supprimé ouvert, donc l’espace reste occupé alors que le chemin disparaît. Faites tourner ou tronquez les journaux via la procédure correcte du service.

Quelle quantité d’espace libre la partition système doit-elle conserver ?

Il n’y a pas de pourcentage universel. Gardez suffisamment de marge pour les mises à jour, journaux, maintenance de base de données, croissance des conteneurs et opérations de récupération, puis alertez à la fois sur le taux de croissance et la quantité restante.