Linux et le manque d’inodes « No space left on device » : comment résoudre ce problème ?
I. Présentation
Sur un serveur Linux, il n'est pas rare de croiser le message d'erreur "No space left on device", ce qui peut engendrer d'autres problèmes, notamment des services qui ne démarrent plus. Parfois, on peut être surpris de ce message d'erreur, car il reste bien de l'espace disque sur le volume : que se passe-t-il ?
Lorsqu'il n'y a plus d'espace disque sur un système Linux, le premier réflexe c'est d'utiliser la commande "df" pour voir l'état des différents volumes.
df -h
Si l'on voit qu'un volume est utilisé à 100%, alors on comprend l'apparition du message "No space left on device", mais si le résultat montre qu'il reste de la place sur le disque, on peut sembler un peu confus face à cette situation. Voici un exemple ci-dessous où il reste de la place sur le disque, et pourtant le message d'erreur apparaît.
La réponse se situe au niveau des inodes. En effet, sur un même volume, le nombre de fichiers est limité ! Ainsi, on peut saturer un volume avec un très grand nombre de petits fichiers sans pour autant saturer l'espace disque en lui-même.
II. Quelques mots sur les inodes
Sous Linux, chaque fichier est associé à un inode qui sert de descripteur pour ce fichier (métadonnées). Le nombre d'inodes, ou nœuds d'index en français, car inode c'est la contraction de "index" et "node", est limité sur un volume. Pour connaître la limite d'inodes, il faut analyser la configuration du serveur, car cela dépend de la taille du volume. La commande "df" est toujours notre alliée, sauf que l'on va utiliser l'option "-i" qui permet d'obtenir des informations sur les inodes plutôt que les blocs.
df -i
Ainsi, il est fort probable que vous trouviez une ligne avec un "100%". Par exemple :
Sys. de fichiers Inœuds IUtil. ILibre IUti% Monté sur
udev 1014029 367 1013662 1% /dev
tmpfs 1018474 583 1017891 1% /run
/dev/mapper/SRV--WWW--1--vg-root 6463488 6463488 0 100% /
On peut voir que pour saturer une partition, il faut vraiment un très très grand nombre de fichiers : ici, plus de 6,4 millions de fichiers ! En mettant en place de la supervision sur les inodes, on peut recevoir une alerte et anticiper le problème avant d'arriver à saturation :
Un script qui s'emballe, une application non optimisée, etc.... Peuvent être la cause de cette erreur, et il faudra parvenir à l'identifier afin de supprimer des fichiers, car pour résoudre le problème, il est indispensable de supprimer des fichiers (sans parler de la possibilité d'étendre le volume). Dans le dernier cas de ce type que j'ai rencontré, c'est une mauvaise gestion des sessions PHP (qui s'accumulaient sans cesse) qui était à l'origine de ce problème.
III. Comment supprimer des fichiers ?
La suppression des fichiers est une opération simple réalisable à partir de la commande "rm". Cependant, puisqu'il n'y a plus d'inodes disponibles sur la machine et qu'il y a une quantité très importante de fichiers à supprimer, ce n'est pas si évident. La commande "rm" classique, à savoir :
rm /var/www/site/sessions_php/* -Rf
Ne fonctionnera pas, car il y a trop de fichiers à supprimer ! Elle va retourner l'erreur suivante :
-bash: /usr/bin/rm: Liste d'arguments trop longue
Dans ce cas, l'idéal c'est de se positionner dans le dossier qui contient tous les fichiers à supprimer (c'est important de se positionner dans le dossier !) :
cd /var/www/site/sessions_php
Puis, d'exécuter la commande suivante basée sur une recherche find pour rechercher et supprimer tous les fichiers sous cette racine :
find . -name '*' -type f -exec rm -f {} \;
Si cela retourne une erreur, il faut essayer d'ajuster le filtre pour créer des groupes de fichiers à supprimer afin d'y aller par pool de fichiers. Une fois cette opération effectuée, le serveur va retrouver son fonctionnement normal : n'oubliez pas de vérifier l'état du volume avec la commande vue précédemment.
A non flo ta pas le droit :p
find . -name ‘*’ -type f -exec rm -f {} \;
le mieux c’est plutôt
find . -name ‘*’ -type f -delete
Bonne journée