Le disque se remplit lentement mais aucune modification de taille de fichier visible

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 de 60% hier et il atteindra 100% dans quelques jours.

Je surveille les fichiers depuis un moment 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

Cela me donne (plus ou moins) les mêmes chiffres chaque jour. Ce total de 14 G représente moins de 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 les fichiers ne s'affichent pas ici? Est-il possible d'avoir de l'espace alloué d'une autre manière?

S'il y a une croissance invisible de l'espace disque, un coupable probable serait 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 lâche prise. Dans certains cas, cela peut être utilisé comme un bon moyen de nettoyer après vous - même - les plantages d'applications n'empêcheront pas les fichiers temporaires d'être nettoyés.

Pour consulter les fichiers supprimés et encore 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 la lsofsortie) et redémarrez ou fermez celles qui semblent raisonnables.

Si jamais 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 comme source d'utilisation de disque volumineux (mais vous devez toujours redémarrer le programme pour que les corrections de bogues s'appliquent).

Les fichiers /dev/shmsont des objets de mémoire partagée et n'occupent pas beaucoup d'espace sur le disque (un nombre d'inode au maximum, je pense). Ils peuvent également être ignorés en toute sécurité. Les fichiers nommés vteXXXXXXsont des fichiers journaux d'un émulateur de terminal basé sur VTE (comme GNOME Terminal, Terminator, etc.). Celles - ci pourraient être grandes, si vous avez une fenêtre de terminal ouverte avec beaucoup (et je veux dire beaucoup ) de choses en cours de sortie.

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

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

Peut-être que ce que vous ne voyez pas avec du est l'apparence de beaucoup, beaucoup de petits fichiers ... (regardez dans la dernière colonne de df -iet voyez si le nombre d'inodes (c'est-à-dire de fichiers) augmente aussi beaucoup d'heures supplémentaires)

Si vous avez, disons, 1'000'000 (1 million) de minuscules fichiers de 1 octet, ducela comptera comme 1'000'000 octets au total, disons 1 Mo (... puristes, s'il vous plaît, ne grincez pas les dents)

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

• 1 inode (pointant vers les données du fichier), et cet inode peut à lui seul faire 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 fichiers 1 octet occuperont 1'000'000'000 * size_of_a_blockl'espace total pour les données, plus 1'000'000'000 * size_of_an_inodela taille de l'inode ... Cela peut représenter plusieurs Go d'utilisation du disque pour 1 million de fichiers "1 octet".

Si vous avez des blocs de 1024 octets et 256 autres octets de taille d'inode, vos fichiers 1'000'000 seront rapportés à environ 1 Mo par du, mais compteront à peu près 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)

Si /dev/vda1se remplit, cela peut être dû à Jenkins ou Docker (ou etc.) et vous devrez peut-être utiliser la lsofcommande pour nettoyer les journaux et définir sa taille .