Disque se remplissant lentement mais pas de changement de taille de fichier visible

16
  

df

 Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda1       30830588 22454332   6787120  77% /
none                   4        0         4   0% /sys/fs/cgroup
udev             1014124        4   1014120   1% /dev
tmpfs             204996      336    204660   1% /run
none                5120        0      5120   0% /run/lock
none             1024976        0   1024976   0% /run/shm
none              102400        0    102400   0% /run/user

Ce 77% n’était que 60% hier et il se remplira à 100% dans quelques jours.

Je surveille les résultats depuis un certain temps maintenant:

sudo du -sch /*


9.6M    /bin
65M     /boot
224K    /build
4.0K    /dev
6.5M    /etc
111M    /home
0       /initrd.img
0       /initrd.img.old
483M    /lib
4.0K    /lib64
16K     /lost+found
8.0K    /media
4.0K    /mnt
4.0K    /opt
du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory
0       /proc
21M     /root
336K    /run
12M     /sbin
8.0K    /srv
4.1G    /swapfile
0       /sys
4.0K    /tmp
1.1G    /usr
7.4G    /var
0       /vmlinuz
0       /vmlinuz.old
14G     total

Ça me donne (plus ou moins) les mêmes chiffres chaque jour. Ce total 14G est inférieur à la moitié de la taille du disque. Où va le reste?

Ma connaissance de Linux ne va pas beaucoup plus loin.

Est-il possible que des fichiers ne s'affichent pas ici? Est-il possible d'avoir de l'espace alloué d'une autre manière?

    
posée nizzle 24.09.2015 - 08:59
la source

2 réponses

27

S'il y a une croissance invisible dans l'espace disque, un coupable serait probablement les fichiers supprimés. Sous Windows, si vous essayez de supprimer un fichier ouvert par quelque chose, vous obtenez une erreur. Sous Linux, le fichier sera marqué comme supprimé, mais les données seront conservées jusqu'à ce que l'application soit libérée. Dans certains cas, cela peut être utilisé comme un bon moyen de faire le ménage après vous-même . d'être nettoyé.

Pour voir les fichiers supprimés et toujours utilisés:

lsof -b 2>/dev/null | grep deleted

Vous pouvez avoir un grand nombre de fichiers supprimés - cela en soi n’est pas un problème. Un seul fichier supprimé qui devient volumineux est un problème.

Un redémarrage devrait résoudre ce problème, mais si vous ne souhaitez pas redémarrer, vérifiez les applications impliquées (première colonne dans lsof output) et redémarrez ou fermez celles qui semblent raisonnables.

Si vous voyez quelque chose comme:

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

Lorsque l’application et les fichiers supprimés sont identiques, cela signifie probablement que l’application a été mise à niveau. Vous pouvez ignorer ceux-ci en tant que source d'utilisation de disque volumineux (mais vous devez toujours redémarrer le programme pour que les correctifs s'appliquent).

Les fichiers dans /dev/shm sont des objets de mémoire partagée et n'occupent pas beaucoup d'espace sur le disque (un nombre d'inodes au plus, je pense). Ils peuvent également être ignorés en toute sécurité. Les fichiers nommés vteXXXXXX sont des fichiers journaux d'un émulateur de terminal basé sur VTE (comme le terminal GNOME, Terminator, etc.). Ces pourraient être volumineux, si vous avez une fenêtre de terminal ouverte avec beaucoup (et je veux dire beaucoup ). en cours de sortie.

    
réponse donnée muru 24.09.2015 - 09:59
la source
2

Pour ajouter à l'excellente réponse de muru:

  • df affiche la taille sur le disque,
  • et du affiche la taille totale du contenu des fichiers.

Peut-être que ce que vous ne voyez pas avec du est l’apparition de beaucoup de petits fichiers ... (regardez la dernière colonne de df -i et voyez si le nombre d’inodes (c.-à-d. de fichiers) augmente beaucoup les heures supplémentaires aussi)

Si vous avez, disons, 1 000 000 (1 million) de petits fichiers d’un octet, du comptera 1 000 000 octets au total, disons 1 Mo (... puristes, s'il vous plaît ne pas grincer)

Mais sur disque, chaque fichier est composé de 2 éléments:

  • 1 inode (pointant vers les données du fichier), et cet inode peut être à lui seul 16kb (!),
  • Et les données de chaque fichier (= le contenu du fichier) sont placées sur des blocs de disque, et ces blocs ne peuvent pas contenir plusieurs données de fichier (généralement ...), donc votre 1 octet de données occupera au moins 1 bloc

Ainsi, un million de fichiers de 1 octet occuperont 1'000'000'000 * size_of_a_block de l'espace total pour les données, plus 1'000'000'000 * size_of_an_inode de la taille de l'inode ... Cela peut représenter plusieurs Go de disque pour 1 million de "1 octet" fichiers.

Si vous avez des blocs de 1024 octets et un autre de 256 octets de taille d’inode, vos 1'000'000 fichiers seront rapportés à environ 1Mb par du , mais compteront approximativement 1.25 Go sur le disque (comme vu par df )! (ou même 2 Go si chaque inode doit également être sur 1 bloc de disque dédié ... Je ne sais pas si c'est le cas)

    
réponse donnée Olivier Dulac 24.09.2015 - 18:48
la source

Lire d'autres questions sur les étiquettes