Forum Linux.gentoo Où est utilisé mon espace disque ?

Posté par  .
Étiquettes : aucune
3
4
nov.
2010
Bonjour à tous,

Je viens en quête d'une solution à mon problème d'espace disque sur mon / qui est rempli à 100% à quelques kilo prêt, sauf que je ne trouve pas ce qu'il le rempli avec la commande du -hs faite répertoire par répertoire qui sont sur le /.

Pour info je suis un novice en Gentoo et je reprend un serveur qui n'a pas été monté par moi.

Voici les informations dont je dispose :
uname -a donne :
Linux server-gentoo 2.6.28-gentoo-r1 #1 SMP Fri Feb 6 17:46:31 CET 2009 x86_64 Intel(R) Xeon(R) CPU 5140 @ 2.33GHz GenuineIntel GNU/Linux


mount donne :
rootfs on / type rootfs (rw)
/dev/root on / type xfs (rw,noatime,attr2,noquota)
/proc on /proc type proc (rw)
rc-svcdir on /lib64/rc/init.d type tmpfs (rw,nosuid,nodev,noexec,size=1024k,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec)
udev on /dev type tmpfs (rw,nosuid,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,gid=5,mode=620)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec)
/dev/sda3 on /usr type xfs (rw,noatime,logbufs=8)
/dev/sda6 on /var type xfs (rw,noatime,logbufs=8)
/dev/sda7 on /ccache type xfs (rw,noatime,logbufs=8)
/dev/sda8 on /home type xfs (rw,noatime,logbufs=8)


cat /etc/fstab donne :
/dev/sda1 /boot reiserfs notail,noauto,noatime 1 2
/dev/sda2 / xfs noatime,logbufs=8 0 1
/dev/sda5 none swap sw 0 0
/dev/sda3 /usr xfs noatime,logbufs=8 0 2
/dev/sda6 /var xfs noatime,logbufs=8 0 2
/dev/sda7 /ccache xfs noatime,logbufs=8 0 0
/dev/sda8 /home xfs noatime,logbufs=8 0 2
proc /proc proc defaults 0 0
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0


cat /etc/mtab donne :
rootfs / rootfs rw 0 0
/dev/root / xfs rw,noatime,attr2,noquota 0 0
/proc /proc proc rw 0 0
rc-svcdir /lib64/rc/init.d tmpfs rw,nosuid,nodev,noexec,size=1024k,mode=755 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec 0 0
debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,nosuid,size=10240k,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,noexec 0 0
/dev/sda3 /usr xfs rw,noatime,logbufs=8 0 0
/dev/sda6 /var xfs rw,noatime,logbufs=8 0 0
/dev/sda7 /ccache xfs rw,noatime,logbufs=8 0 0
/dev/sda8 /home xfs rw,noatime,logbufs=8 0 0
usbfs /proc/bus/usb usbfs rw,noexec,nosuid,devmode=0664,devgid=85 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,noexec,nosuid,nodev 0 0


fdisk -l donne :
Disque /dev/sda: 1499.2 Go, 1499212021760 octets
255 heads, 63 sectors/track, 182268 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Périphérique Amorce Début Fin Blocs Id Système
/dev/sda1 1 14 112423+ 83 Linux
/dev/sda2 15 1352 10747485 83 Linux
/dev/sda3 1353 3298 15631245 83 Linux
/dev/sda4 3299 182268 1437576525 5 Extended
/dev/sda5 3299 4393 8795556 82 Linux swap / Solaris
/dev/sda6 4394 6339 15631213+ 83 Linux
/dev/sda7 6340 6705 2939863+ 83 Linux
/dev/sda8 6706 10353 29302528+ 83 Linux
/dev/sda9 10354 182268 1380907206 8e Linux LVM


La fragmentation du système de fichier XFS est de 0.77%


df -h donne :
Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur
rootfs 11G 11G 692K 100% /
/dev/root 11G 11G 692K 100% /
rc-svcdir 1,0M 76K 948K 8% /lib64/rc/init.d
udev 10M 128K 9,9M 2% /dev
shm 996M 0 996M 0% /dev/shm
/dev/sda3 15G 4,7G 11G 32% /usr
/dev/sda6 15G 253M 15G 2% /var
/dev/sda7 2,8G 414M 2,4G 15% /ccache
/dev/sda8 28G 4,3M 28G 1% /home

La somme de tous les du -hs sur les répertoires bin boot etc home lib lib32 lib64 mnt opt proc root sbin sys tmp est inférieur à 500Mo

Après reboot du serveur tout reste identique.

Dans tous les résultats des commandes je vous ai épargné la baie de disque externe.

Si quelqu'un arrive à déceler d'où vient cet écart entre le les 11Go d'occuper d'après df et ma somme de du des répertoires je suis preneur, surtout que j'ai une bonne dizaine d'autre serveur qui ont la même conf, même partitionnement, monté à la même date et qui ont des df égaux à ma somme des du pour le / avec une utilisation générale inférieur de 500 Mo / 11Go !

  • # L'analiseur graphique d'utilisation?

    Posté par  (site web personnel) . Évalué à 2.

    Un petit utilitaire graphique est présent sous la plupart des distributions, Analyseur d'utilisation des disques. Très agréable et permet de savoir où faire le nettoyage en cas de besoin ;). (dans le menu accessoires)

    Après si c'est du à une multiplication de petits fichiers, tu peux utiliser les comandes proposées dans ce sujet:
    http://linuxfr.org/forums/47/29317.html

    • [^] # Re: L'analiseur graphique d'utilisation?

      Posté par  . Évalué à 2.

      Je n'ai pas d'interface graphique, c'est un serveur de production ^^

      Je vais tester les commandes proposées dans l'autre sujet, mais je ne pense pas que cela ne vienne de là car j'ai très peu de fichier.

    • [^] # Re: L'analiseur graphique d'utilisation?

      Posté par  . Évalué à 2.

      Donc en tout et pour tout je n'ai que moins de 21.000 fichiers de directement sur / (dont près de 15.000 rien que pour /proc) et donc en admettant que chaque fichier prennent 4k pour un index (je compte large hein) ça ne fait que 84Mo d'espace disque auquel on ajoute la taille réelle des fichiers que la commande du comptabilise à largement moins de 500Mo

      • [^] # Re: L'analiseur graphique d'utilisation?

        Posté par  (site web personnel) . Évalué à 2.

        C'est au-delà de mes compétences pour te dire si cela fait beaucoup ou pas pour un serveur, ou si ton estimation de la taille des fichiers est valide. Je peux , au mieux, pour te donner une indication de taille de dire la taille de mon fichier proc:
        "36 901 éléments, total 1016,4 Mio
        (certains éléments sont impossibles à lire)"
        Mais sous Mint, pour une station de travail personnelle...

        En gros je dirais que j'ai deux fois plus de fichiers dans Proc et cela prends deux fois plus de place donc c'est cohérent.

        Essaie peut être de vider les fichiers genre corbeille et autres. Il m'est déjà arrivé (suite à une erreur de manip et un plantage) de créer un fichier prenant tout le reste du disque mais ne se trouvant pas à l'endroit ou il devait s'enregistrer. Le nettoyage l'a effacé et m'a rendu la main sous le système (dans mon cas il ne me restait 2 ko d'espace disque disponible).

        (d'ailleurs pourquoi lorsque le disque est complet propose t'on en premier de supprimer la barre de menu et non la corbeille?)

  • # le tmp est dans la racine ?

    Posté par  (site web personnel) . Évalué à 1.

    Tout est ds le titre

    Système - Réseau - Sécurité Open Source

    • [^] # Re: le tmp est dans la racine ?

      Posté par  . Évalué à 1.

      Oui il est à la racine mais tout comme sur les autres serveurs, le tmp ne dépasse jamais les 4ko d'utiliser et ce uniquement quand les cron se déclenchent

  • # Mes 2 cts

    Posté par  . Évalué à 1.

    un fichier caché ?
    ls -al pour le voir sur /

    • [^] # Re: Mes 2 cts

      Posté par  . Évalué à 1.

      Non aucun fichier caché à la racine, j'avais oublié de le précisé.

  • # fsck ?

    Posté par  (site web personnel) . Évalué à 2.

    Le système de fichier est peut-être corrompu. As-tu lancé un fsck pour vérifier/corriger les problèmes ?

    Autre idée : Je ne sais pas pour xfs, mais pour ext, il y a un répertoire "lost+found" qui regroupe les fichiers "trouvés" par un fsck.ext qui ne correspondent plus à rien (typiquement, suite à un reboot violent de la machine). Peut-être que xfs a un tel mécanisme, et que ce répertoire est plein de ce type de fichiers ?

    • [^] # Re: fsck ?

      Posté par  . Évalué à 1.

      Alors non on ne peut pas faire de fsck sur une partition xfs mais j'ai trouvé que je pouvais faire un xfs_repair en single user sur la partition non monté (je dois surement pouvoir le faire également via un live cd)

      Bon maintenant reste à voir quand je pourrais tester cela ^^

      Et sinon pour info il n'y a pas de lost+found sur un système de fichier xfs.

      Je vous tiendrais au courant des résultats du xfs_repair ;)

      • [^] # Re: fsck ?

        Posté par  . Évalué à 1.

        Le xfs_repair n'a rien donné, la partition est ok !

  • # Fichier caché par un montage ?

    Posté par  . Évalué à 8.

    T'as peut-être une fichier qui est "sous" un de tes (nombreux, on sent le mec qui a voulu faire simple ...) montages.

    Soit tu démontes tous les sous-répertoires, mais comme tu es en prod ... Tu peux tenter un remontage de la racine autre part :
    mount -o bind / /quelque_part/racine_sans_sous_montages

    Et de là tu pourras supprimer ce qui prend de la place.

    • [^] # Re: Fichier caché par un montage ?

      Posté par  . Évalué à 5.

      oui ça sent les fichiers masqués par un montage :)
      Moi je vote sous ccache :)

      Si y a konqueror (oui je sais c'est un serveur, mais quand même), l'afficheur de taille de fichier est génial.

      (évidemment a utiliser après la commande donnée par le geek précédent :D )

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Fichier caché par un montage ?

        Posté par  . Évalué à 1.

        Alors le répertoire /ccache est sur une autre partition (/dev/sda7) et ne contient que 394Mo de données ^^

        J'ai quelque chose comme 10Go au bas mot qui reste invisible !

        • [^] # Re: Fichier caché par un montage ?

          Posté par  (site web personnel) . Évalué à 2.

          C'est pourquoi il te proposes de vérifier dessous (et pas dedans). Démonte ccache et vérifie cela, dès fois qu'il y ai du ménage à faire ...

          • [^] # Re: Fichier caché par un montage ?

            Posté par  (site web personnel) . Évalué à 2.

            Exemple plus causant :

            du -h /
            34G
            du -h /machin
            10G

            mount /dev/sda7 /machin
            du -h /machin
            4.0K
            du -h /
            34G

            Soit la proposition de vérifier qu'avant de monter une partition spéciale pour lui, ccache n'est pas été utilisé et non nettoyé... et du coup contient un gros fatra oublié... Qui, éventuellement, pourrait être déplacé sur /dev/sda7... M'enfin bon maintenant que c'est en prod, tu ne devrais plus avoir besoin de ccache

    • [^] # Re: Fichier caché par un montage ?

      Posté par  . Évalué à 7.

      Bingo c'était ça !

      En faite c'est la baie de disque qui n'avais pas dû être monter pour une raison ou une autre du coup des rsync ont écrit sur le point de montage de / au lieu de la baie de disque.

      J'ai pu le voir en montant le / sur un live cd.

      Merci à tout le monde pour leur précieuse aide (me remettre dans le droit chemin ^^), et en espérant que mon problème pourra aider d'autre personne !

    • [^] # Re: Fichier caché par un montage ?

      Posté par  . Évalué à 3.

      on sent le mec qui a voulu faire simple
      On sent le mec qui est habitué à voir des serveurs en prod, ce genre d'install est très classique, et plus que conseillé. Ca permet plein de choses: que les logs ou /tmp ne bouffent pas tout, de pouvoir monter / et /usr et ro etc

  • # i noeud ! Une classique...

    Posté par  (site web personnel) . Évalué à 4.

    Alors un classique de ce genre de truc :
    La suppression de fichier sans surpression de l'i-noeud !

    - Typiquement tu as un programme qui écrit dans un log, tu rm le log, ben le fichier est plus visible mais bouffe de l'espace.

    - En plus il continue de grossir car un file descriptor pointe vers un i-noeud et pas un filename comme sous zin ce qui fait que tu peux renommer les fichier en cours d'utilisation ).
    1 inconvéniant, 1 avantage...

    Tu peux voir avec un lsof les pointeurs / flux sur des fichiers suprimé...
    Pour résoudre temporairement : reboot...
    A surveiller, si c'était une erreur humaine ca va, mais ca peux être un script de purge mal pensé..

    Fuse : j'en Use et Abuse !

  • # fichiers de logs effacés mais process qui continue de le remplir

    Posté par  . Évalué à 2.

    ca fait parfois ca quand tu n'as plus de place, tu effaces des fichiers de logs
    ils n'apparaissent donc plus dans un ls ou dans un du

    mais comme ils sont encore en cours d'usage par le programme qui logue dedans
    les inodes sont toujours ouverts et l'ocuppation disque n'a pas changé.

Suivre le flux des commentaires

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