Forum Linux.debian/ubuntu Où es passé l'espace libre sur ma partition?

Posté par (page perso) .
Tags : aucun
1
30
mar.
2009
Bonjour,

J'essaye de régler un problème d'imprimante, et au fur et à mesure que je libère de la place sur ma partition /var elle est mangée.

j'ai déjà libéré plus de 500Mo, et maintenant, il n'y a plus d'espace libre.
La partition fait 4.3Go.

J'ai pensé à l'espace réservé au root, mais à un moment, j'avais 95% d'occupé.
Maintenant, c'est complètement saturé.

J'ai lancé la commande suivante :
df -hDs * en étant dans /var cela donne :

:/var# du -hDs *

8,6M backups
80M cache
389M lib
0 local
0 lock
56M log
4,0K mail
0 opt
113K run
1,1M spool
17M tmp
1,5G www

J'ai donc environ 3 Go de données qui se sont envolées.
/dev/hda5 4425716 4425716 0 100% /var
La partition /var est au format reiserfs.
Il n'y a rien d'anormal remonté avec smartmontool, et je ne vois rien d'anormal dans les logs.

Comment retrouver l'espace perdu?
Le poste est sous GNU/Linux Debian testing/sid/experimental (selon les besoins... avec les derniers noyaux disponibles via aptitude).

A bientôt
Grégoire
  • # calcul ?

    Posté par . Évalué à 3.

    :/var# du -hDs *

    8,6M backups
    80M cache
    389M lib
    0 local
    0 lock
    56M log
    4,0K mail
    0 opt
    113K run
    1,1M spool
    17M tmp
    1,5G www


    1.5Go + 389Mo + 80Mo + 56Mo + 17Mo + 8.6Mo + 1.1Mo = 2051Mo
    soit environ 2Go

    sur une partition de 4.3Go,
    tu auras par defaut 5% (251Mo) reservé à root.

    tu as donc deja 2.3Go de données

    il te manquerait donc 2Go

    as-tu vidé la corbeille ?
    n'y aurait-il pas des dossiers cachés (non visible avec ton du -HdS *) ?
  • # un classique ...

    Posté par . Évalué à 5.

    un daemon ou une application remplit un fichier qui a été supprimé.
    La référence du fichier dans le répertoire a disparu, mais le fichier en lui même es toujours ouvert et continue de se remplir ....

    Il faut donc trouver le process qui écrit ledit fichier et arrêter/relancer le process.
    • [^] # Re: un classique ...

      Posté par (page perso) . Évalué à 2.

      Bonsoir

      J'ai essayé de voir ce que ça donne au niveau des fichiers caché, mais je vais devoir chercher un peu plus de ce côté.

      Pour le démon qui tourne, ça ne compte pas, parce que j'ai redemmaré alors qu'il restait pas mal de place (des dizaines de Mo).

      J'ai regardé avec iotop, et les écritures dans les fichiers de logs sont faibles (et le dossier des log n'est pas gros).

      Je vais déplacer les fichiers de /var/www/ parce que je n'ai plus de serveur web qui tourne, ce ne sont que des archives pour moi.

      Je vais voir de près tout ça. (démon, fichiers cachés).

      Merci.

      A bientôt
      Grégoire
      • [^] # Re: un classique ...

        Posté par . Évalué à 2.

        Salut,

        Je vais rebondir sur les remarques précédentes...

        NeoX parle des 5% réservés à root par défaut : c'est vrai sur les filesystems de type ext{2,3,4}. Ici, le FS est formaté en reiserfs : il n'y a pas d'espace réservé à root. Accessoirement, il est possible de réduire ces espace réservé sur un FS ext3 en passant l'option -m <valeur_en_%> à mkfs.ext3 ou à tune2fs (sur de grosses partitions de données, cela peut être très utile).

        L'explication donné par totof2000 me semble pertinente : un fichier ouvert en écriture a été supprimé. Ce fichier n'apparaît plus avec un ls ou dans le résultat du du, mais le process qui l'utilise continue d'écrire dedans. Tu peux repérer ces fichiers avec la commande :
        lsof | grep -i deleted
        Ceci te permettra de voir le process et son PID ainsi que la taille et el nom des fichiers supprimés mais toujours présents sur le disque.

        Il sera ensuite intéressant de se demander pourquoi un, ou plusieurs, processus se sont mis à bouffer autant de place sur le disque : ça traduit certainement un problème annexe.

        A+
        JJD
  • # Et le nombre d'inode ?

    Posté par . Évalué à 2.

    Peux tu faire un df -i pour vérifier s'il reste des inodes de libres?
  • # Finalement...

    Posté par (page perso) . Évalué à 2.

    Bonjour,

    hier soir, j'ai éteint le poste, et quand je suis revenu sur place, je l'ai relancé.
    Il y avait bien mes 2,9Go de libre :) donc la thèse du fichier ouvert et éffacé semble la bonne piste.

    Pendant que j'observai l'activité sur cette partition, j'ai vu une activité louche... ha oui, cette saloperie de updatedb.mlocate que je n'arrive pas à annuler, peut être que c'est ça qui m'a mangé une partie de l'espace disque, j'ai beaucoup de fichiers (surtout des images).

    Je note dans mon carnet les commandes pour voir les inodes, et les fichiers effacé, et heu... on verra dès que j'aurai trouvé ce qui va pas.

    Concernant updatedb, je suis persuadé d'avoir modifié le fichier dans le cron.dayli, je viens de vérifier de nouveau, et le script est là, tout propre... arrrgh! (daté du 2 mars 2009)

    Comment peut-on planter un couteau dans le dos de mlocate? vu que je ne me sers pas de cette chose (utile s'il ne pouvait analyser QUE certains dossiers), et vu que mon aptitude fonctionne de nouveau, j'ai viré le paquet mlocate (et zou!) (curieux, le dossier /var/lib/mlocate/ ne fait que 11Mo.)

    Au final : je ne sais pas encore ce qui s'est vraiment passé, mais je vais finir par le savoir :)

    merci.

    A bientôt
    Grégoire
    • [^] # Re: Finalement...

      Posté par (page perso) . Évalué à 4.

      > Comment peut-on planter un couteau dans le dos de mlocate? vu que je ne me sers pas de cette chose (utile s'il ne pouvait analyser QUE certains dossiers)

      Il peut. Enfin, j'ai le updatedb de locate et non mlocate, et j'ai édité /etc/cron.daily/locate en ajoutant au PRUNEPATH les dossiers que je ne veux pas voir scannés.

      Si tu veux le désactiver, il doit suffire de supprimer le fichier en question. Mais il risque d'être réinstallé après update (alors que modifier le PRUNEPATH résiste à la mise à jour).
  • # Voici deux pistes.

    Posté par . Évalué à 2.

    Première piste.
    En root, place ton système en mode maintenance (init 1), démonte la partition /dev/hda5 puis lance reiserfsck sur cette partition (l'option --check permet de ne rien modifier sur la partition) :
    # init 1
    # umount /dev/hda5
    # reiserfsck --check /dev/hda5

    Seconde piste.
    Que donne la commande suivante qui affiche les fichiers d'une taille de plus d'1 Mo dans /var :
    # find /var -size +1024k | ls -lh

    Bon courage.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.