Discussion :

[veis]

Bonjour à tous.
Je rencontre un soucis sur un de mes serveurs, problème que je n'avais encore jamais rencontré...
J'ai un filesystem faisant 3936MB.
Lorsque je fais un df -m, il m'indique 321,34 MB de libre, soit 92% d'occupation.
Je vais donc pour faire un peu de ménage, et lorsque je me positionne dans mon répertoire où se trouve le point de montage, je fais un du -sm . et là je n'ai que 1548,95MB d'occupation...
J'ai donc environ 2400MB qui ne sont... nulle part...
Je n'ai jamais vu ça, et du coup ça m'ennuie pas mal parce que le FS est proche du remplissage et j'aimerais éviter que ça plante...

Si quelqu'un a déjà rencontré ce genre de soucis... Ou aurait une idée de comment voir où part cette occupation disque...
Merci d'avance pour votre aide.

Bonne journée.

[veis]

Je viens de trouver une anomalie qui pourrait peut-être expliquer le post initial...
Lorsque je fais un ls -l, certains de mes fichiers me donnent une taille, qui est différente de celle que je trouve avec un du...
Notamment, j'ai un fichier de log qui tourne toutes les heures, et au moment de sa rotation (qui est faite par un echo > monFichier, mais même avec un cp /dev/null monFichier, ou avec un :< monFichier, ça donne le même résultat), sa taille est remise à 0 avec un du, mais si je fais un ls -l, il repart directement à 62******, soit près de 62MB...
J'ai trouvé deux fichiers avec cette incohérence dans le résultat des commandes, mais il y en a peut-être d'autres dans d'autres sous répertoires de ce FS, ce qui pourrait peut-être expliquer mes 2,4GB manquants... Mais par contre, je ne sais quand même pas expliquer cette incohérence...

Help ?

[everest31]

En principe un restart du service qui gère ce ou ces fichiers de log résout le problème de la taille.

j'ai eu aussi ce genre d'erreur et j'en ai déduis qu'en fait le daemon qui tourne sur le fichier de log ne prend pas en compte le fait que le fichier a était vidé et pour lui il indique toujours la taille qu'il pensent être la bonne au filesystem.

En gros pour eviter ce problème, quand je tourne mes fichiers de log, je fais toujours un restart ou un reload des services associés et ca marche nickel.

[jlliagre]

Je viens de trouver une anomalie qui pourrait peut-être expliquer le post initial...
Lorsque je fais un ls -l, certains de mes fichiers me donnent une taille, qui est différente de celle que je trouve avec un du...

Ce n'est pas une anomalie mais un comportement normal sous Unix.

Notamment, j'ai un fichier de log qui tourne toutes les heures, et au moment de sa rotation (qui est faite par un echo > monFichier, mais même avec un cp /dev/null monFichier, ou avec un :< monFichier, ça donne le même résultat), sa taille est remise à 0 avec un du, mais si je fais un ls -l, il repart directement à 62******, soit près de 62MB...

Ce n'est pas une procédure correcte pour faire une rotation de fichier. Le fichier résultant est un "sparse file" mais ce n'est pas la cause de l'espace disque manquant. Le problème est certainement du à des fichiers de logs effacés (rm) mais qui sont toujours ouverts par les applications écrivant dedans. Tant que des programmes accèdent à ces fichiers, leur espace disque est occupé. Il faut comme everest31 l'a déjà suggéré redémarrer ces applications.

[veis]

Bonjour,

Effectivement, un redémarrage des services écrivant dans ce fichier de log a corrigé cet effet bizarre, il est bien retombé à 0 pendant l'arrêt et il grossis à nouveau normalement après la relance des services.
En revanche j'ai toujours ce problème de différence énorme entre l'espace libre donné par mon df et l'espace occupé donné par un du.
Je sais que les valeurs ne sont pas censées être identiques avec les calculs des blocks etc... mais de là à avoir 2,2GB qui ont disparu...
Je ne comprends pas...

[everest31]

Il n'y aurait pas d'autres services avec des fichiers de log qui poseraient le même problème ?

Sinon, faire un fsck devrait peut etre permettre de remettre de l'ordre dans ton filesystem.

Déjà, il faudrait voir a quel niveau se situe la perte de place dans un répertoire particulier ou sur toute la partition.

[veis]

Ce serait sur tout le FS à priori car je fais un du -sm . à la racine du filesystem et je trouve 1550MB alors que je suis censé avoir 3700MB d'occupé...
Le problème est que je ne peux pas faire un fsck comme ça, ça créerait une indisponibilité du système, et bien évidemment le client ne le permet pas...

[everest31]

alors ca va etre assez problématique.

Par contre tu peux quand meme lancé un fsck sur la partition montée certes ca ne corrigera pas les problèmes s'il y en a vu que tu n'aura spas l'accés exclusif sur la partition mais au moins tu pourras voir si le fsck trouve de grosses erreurs ou non.

Après si effectivement il y a de grosses erreurs, ben faut proposer au client un down du système la nuit ou le week-end pour réparer parce qu'a mon avis gardé une telle erreur n'est pas bon et risque d'aggraver le problème pour plus tard.

[veis]

On a une maintenance par mois où on éteint tout le système, en dehors, même nuit ou week-end, ce n'est pas possible de couper... (application police/gendarmerie...)
Je n'ai jamais lancé de fsck sur une partition montée par contre... On est sûr qu'il n'y a aucun effet de bord ? (Si ça ne corrige pas ce n'est pas grave sur le moment, mais effectivement si ça me détecte des erreurs au moins j'aurai une piste)

[jlliagre]

On peut utiliser l'option "-n" de fsck pour une partition montée mais je doûte qu'il s'agisse de corruption de système de fichier. Les fichiers ouverts mais effacés sont une cause beaucoup plus courante de ce problème.

Je n'ai pas de machine sous AIX pour tester mais cette commande permet probablement de localiser ces fichiers:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

find /proc/*/fd -type f -links 0 -exec ls -l {} +

[veis]

Bonjour,

Merci pour cette commande, ça me trouve 51 fichiers, dont un de plus de 2GB, ça semble correspondre à mon problème...
J'ai kill le process correpondant au PID présent dans /proc/<PID>/...
et effectivement j'ai retrouvé mon espace sur le FS.

Merci beaucoup pour votre aide !!

[jack-ft]

Donc, si j'ai bien compris, il y avait un process qui avait pris 2Gb de ram (ou de swap disk)!
Peut-on savoir quel était ce process (ça peut servir pour d'autres utilisateurs de ce forum!) et pourquoi il était si gros?

[veis]

En fait ce n'était dans la RAM ou le swap, mais il s'agissait d'un fichier à priori supprimé (par quoi ça par contre je ne sais pas), mais au moment de sa suppression le process qui écrivait dedans n'était pas arrêté. Donc il continuait d'écrire dedans mais vu que le fichier avait été supprimé, on ne pouvait donc pas le voir par un ls ou autre commande du genre sur le filesystem.
Si j'ai bien compris c'est quelque chose comme ça.

Et quant au process lui-même, c'est un process applicatif, donc ça ne sert à rien que j'en donne le nom ou l'utilité puisqu'il est propre au système que j'administre ici, ce n'est pas un process lié à l'OS.

Bonne journée

[jlliagre]

En fait ce n'était dans la RAM ou le swap, mais il s'agissait d'un fichier à priori supprimé (par quoi ça par contre je ne sais pas)

Souvent, il s'agit d'un "rm" fait par un administrateur avec l'intention gagner de la place.

mais au moment de sa suppression le process qui écrivait dedans n'était pas arrêté. Donc il continuait d'écrire dedans mais vu que le fichier avait été supprimé, on ne pouvait donc pas le voir par un ls ou autre commande du genre sur le filesystem.
Si j'ai bien compris c'est quelque chose comme ça.

Tu as bien compris. C'est effectivement la cause la plus probable. Il peut aussi arriver qu'un processus tiers continue à lire un fichier après que le processus qui l'a crée l'ait effacé, ex: "tail -f". Le résultat est identique.