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

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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 ?

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

    • [^] # Re: e2fsck

      Posté par  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . Évalué à 3. Dernière modification le 12 février 2013 à 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 !

  • # Taille vs blocs alloués ?

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

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

  • # "Apparent Size"

    Posté par  (site web personnel) . É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  (site web personnel) . Évalué à 1. Dernière modification le 13 février 2013 à 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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.