Forum

Bonjour

Je me heurte à un problème qui, pour une fois je n'arrive pas à résoudre...

J'explique la situation :

J'ai lors de l'installation de paquets ou d'autres opérations ce message d'erreur : Aucun espace disponible sur le périphérique

Je fais donc un diagnostique rapide :



Bon, si on veut...

Mais en poussant les recherches, je fais la même commande, mais avec l'option -i pour afficher les inodes :



Patatras, c'est tout plein...

Je tape alors la superbe commande



Qui me sort le top10 des dossiers qui utilisent le plus d'inode, avec en tête /var/spool/postfix/maildrop/

Alors,



Mais c'est toujours plein à 100%.... Une piste ?

D'accord, ce dossier est le premier au hit parade, mais peut-être n'est-il le premier que de peu. Je veux dire que si la surconsommation d'inodes est tr-s répartie, supprimer le dossier responsable n'a que peu d'impact.

Est-ce que ta partition / est ancienne, a-t-elle traversé moultes migrations ?

J'ai déjà eu ce problème. En fait il faut en supprimer encore. Puis quand ça ne change encore pas, j'ai rebooté.

Que donne la commande df -i / une fois le dossier supprimé ? Le nombre d'inodes libres a-t-il augmenté ?

Le dossier supprimé affichait 18.000.
Les autres sont /usr/share/man/man3 et /usr/share/man/man1 avec respectivement 5300 et 2322...

La commande df -i / indique maintenant 99% (et le nombre d'inode dispo a un peu augmenté...) ce qui m'a permi de réaliser mon action (une mise à jour)
Le /home étant sur une autre partition, pas d'impact.
J'en ai installé des trucs dessus, (notamment dans /opt) mais j'ai fait le ménage dans /opt et il n'y a plus rien.

/ à un an et demi environ, et n'a pas subi de migration.

Redémarrer le serveur n'a pas libéré plus d'espace....

Est-il possible que le disque soit endommagé et que même s'il reste de l'espace libre (en Go) des inodes soient "désactivés" sur les secteurs défectueux ?

Je pense que non, ton file system serait cassé.



Ma question sur l'ancienneté de la partition et ses migrations était un peu simpliste, mais il faut rechercher quelles activités sont susceptibles de multiplier les petits fichiers, les liens, et certaines caches aussi.



J'aurais parié que le redémarrage ait peu d'effet, il permet la suppression des seuls inodes qui n'étaient pas libérés par des process.

J'ai trouvé, j'avais une multitude de "headers" (de kernels) d'installés, et ils n'étaient pas désinstallés !!!!

Maintenant, je suis à 20% d'inodes utilisés



Et en effet, les headers sont une multitude de petits fichiers

J'ai tout désinstallé sauf ceux du kernel en cours

Si tu as le temps (car tu dois être bien occupé), par curiosité, comment as-tu trouvé ces headers puisque ta mirobolante commande ne les avait mis en exergue ?

Et bien, c'est assez simple en fait...

La piste des petits fichiers ... On en a où ... dans des .h !

Je me suis donc dit, que les fichiers des headers pouvaient être petits...

Et en regardant, j'avais pas moins de 20 versions de kernel sur la machine !!!
J'ai donc, supprimé, c'est vrai, dans un premier temps les kernels pour faire de la place dans /boot, mais les headers n'ont pas été supprimés...
Du coup, dans /usr/src j'avais plein de dossiers, pour chaque version de noyau, avec tous les fichiers nécessaires à la compilation de modules.
Avant de tout supprimer, je fais un méga tar de tout ce contenu et l'archive, je la met sur le /home. Je supprime les fichiers et ... bingo, j'ai l'espace libre.
J'ai alors supprimé l'archive et les paquets RPM en question !

C'est en listant les kernels installés que j'ai vu un très grand nombre d'autres paquets avec le mot kernel dedans, dont les fameux headers.

Du coup, ces nombreux fichiers m'ont pollué la racine (pas bien grande, de 20Go.)

la ligne de commande oui pourquoi pas ...

mais pour trouver simplement les tailles des dossiers et des fichiers baobab est plutôt sympa, l'analyse peut être assez longue mais le résultat est extrêmement détaillés, (tailles des dossiers, sous-dossiers et tous les fichiers contenus)


il y a aussi la vue "tailles des fichiers" de konqueror qui est pas mal


puis même si parfois cela fait un peu n'importe quoi un



aurait surement résolus ton problème

Édité par Visiteur Le 10/12/2014 à 12h23

Vu que le problème est bien dû à la prolifération de petits fichiers planqués dans d'innombrables répertoires, il est probable que si avait été plus grande, tu aurais eu ce même problème plus tard, le même message de filesystem full avec un pourcentage df encore plus bas que 83%.

J'ai eu une fois ce problème au boulot, c'était en prod, tout ce qui se connectait se plantait, on a mis du temps à trouver avec le souffle du directeur sur la nuque