Forum général.général Taille fichier différente entre ls et du

Posté par (page perso) . Licence CC by-sa
Tags : aucun
7
12
fév.
2013

Bonjour,

Sur un serveur j'ai /var qui est plein à 100% (c'est df qui le dit). Je fouille à la recherche des rebelles et je tombe sur un cas :

#ls -l
-rw-r--r-- 1 root root   1374687232 févr. 12 11:00 connections.tdb

du *
269104  connections.tdb

Y aurait pas comme un problème avec la taille des fichiers suivant la commande ?

  • # Yo

    Posté par . Évalué à 1.

    Tu peux faire un du -h connections.tdb suivi d'un ls -h connections.tdb ?

    Zarbi ton problème. T'es sûr que c'est bien le même fichier connections.tdb ? ;)

    • [^] # Re: Yo

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

      du -h /var/lib/samba/connections.tdb --> 263M /var/lib/samba/connections.tdb

      ls -lh /var/lib/samba/connections.tdb --> -rw-r--r-- 1 root root 1,3G févr. 12 11:22 /var/lib/samba/connections.tdb

      Born to Kill EndUser !

      • [^] # Re: Yo

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

        Peux-tu faire un ls -lsh

        Parfois la taille prise par le fichier est différente de la taille du fichier.

  • # e2fsck

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

    Avez-vous vérifié que la partition est saine ? Certaines corruptions de partitions ne pourraient-elle pas aboutir à ce genre d'incohérence ?

    • [^] # Re: e2fsck

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

      J'ai pensé à ça aussi, mais avant j'envoie une demande de support à redhat pour être certain.

      Born to Kill EndUser !

  • # Sparse file

    Posté par . Évalué à 8.

    https://en.wikipedia.org/wiki/Sparse_file

    Par contre, tu as peut-être un petit souci avec ton Samba.

  • # Taille logique != taille physique

    Posté par . Évalué à 10.

    Il est possible que tous les 1374687232 octets ne soient pas physiquement alloués (fichier à trous ou "sparse file").

    Par exemple:

    $ dd if=/dev/zero of=x bs=4k count=1 seek=1048575
    1+0 enregistrements lus
    1+0 enregistrements écrits
    4096 octets (4,1 kB) copiés, 0,000128089 s, 32,0 MB/s
    $ ls -lh x
    -rw-rw-r-- 1 toto toto 4,0G févr. 12 11:35 x
    $ du -h x
    4,0K    x
    
    

    Le fichier a une taille logique de 4 Go mais n'occupe que 4 ko.

    • [^] # Re: Taille logique != taille physique

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

      Ok donc du est plus fiable que ls, mais df se base sur quoi ? logique ou physique ?

      Born to Kill EndUser !

      • [^] # Re: Taille logique != taille physique

        Posté par . Évalué à 7.

        df se base sur le physique.
        Il ne parcourt pas l'arborescence de fichiers pour additionner les tailles mais se contente de compter les blocs marqués comme libres dans une table du système de fichiers (c'est pour ça qu'il est beaucoup plus rapide que du).

  • # Fichier purgé non désalloué

    Posté par . Évalué à 9.

    Il est possible que tu aies des fichiers qui ont été purgés mais sont toujours alloués parce que le process les utilisant ne les a pas fermés.
    df indique alors que l'utilisation est de 100% mais ils sont introuvables avec du.
    Pour les identifier, tu peux faire:

    ls -l /proc/*/fd/* | grep '(deleted)'
    
    
    • [^] # Re: Fichier purgé non désalloué

      Posté par . Évalué à 5.

      ou plus simplement

      lsof -l | grep deleted

    • [^] # Re: Fichier purgé non désalloué

      Posté par (page perso) . Évalué à 3. Dernière modification le 12/02/13 à 13:00.

      Intéressant

      lsof -l | grep deleted
      vmtoolsd   2706        0    7u      REG              253,1       9857     444419 /tmp/vmware-root/appLoader-2706.log (deleted)
      mysqld     3675       27    1w      REG              253,2        367     613690 /var/log/mysql/mysqld-error.log.1 (deleted)
      mysqld     3675       27    2w      REG              253,2        367     613690 /var/log/mysql/mysqld-error.log.1 (deleted)
      mysqld     3675       27    3w      REG              253,2 3621478400     613610 /var/log/mysql/mysql.log.1 (deleted)
      mysqld     3675       27    5u      REG               0,23          0     186996 /sql/tmp/ibVzQY25 (deleted) (192.168.5.11:/vol/ds_nfs_sql_01)
      mysqld     3675       27    6u      REG               0,23        232     186997 /sql/tmp/ibyTNv5M (deleted) (192.168.5.11:/vol/ds_nfs_sql_01)
      mysqld     3675       27    7u      REG               0,23          0     186998 /sql/tmp/ib5w2h8t (deleted) (192.168.5.11:/vol/ds_nfs_sql_01)
      mysqld     3675       27    8u      REG               0,23          0     186999 /sql/tmp/ibgpGdeb (deleted) (192.168.5.11:/vol/ds_nfs_sql_01)
      mysqld     3675       27   12u      REG               0,23        128     187000 /sql/tmp/ibv1STCS (deleted) (192.168.5.11:/vol/ds_nfs_sql_01)
      
      

      le mysql.log.1 pourrait être celui qui me fous le bazar si bien sur la colonne SIZE/OFF correspond à une taille de fichier ?
      Un petit /etc/init.d/mysqld restart et pouf /var occupé à 15%.

      Merci à tous :)

      Born to Kill EndUser !

      • [^] # Re: Fichier purgé non désalloué

        Posté par . Évalué à 6.

        d'apres ce que tu nous dis, et ce qui s'est passé,
        ca voudrait dire que ton logrotate n'est pas configuré pour stopper mysql avant de faire la rotation

        verifie ce point.

  • # Taille vs blocs alloués ?

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

    La taille du fichier ne correspond pas axctement à la taille des blocs alloués ?

  • # "Apparent Size"

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

    Voir ce lien qui comporte les mêmes interrogations:

    although the apparent size is usually smaller, it may be larger due to holes in ('sparse') files, internal fragmentation, indirect blocks, and the like

  • # DU ne sert pas à examiner la taille d'un fichier

    Posté par (page perso) . Évalué à 1. Dernière modification le 13/02/13 à 13:50.

    DU ne sert pas à examiner la taille d'un fichier mais le nombre de blocs effectivement utilisés par le fichier sur le disque. du(1):

    Summarize disk usage of each FILE, recursively for directories.

    Pour ton problème de place dans /var le nombre pertinent est effectivement celui renvoyé par DU. Pour trouver les fauteurs de trouble, tu peux faire

    du | sort -n
    
    

Suivre le flux des commentaires

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