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.