Le disque se remplit lentement mais aucune modification visible de la taille du fichier
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 sera rempli à 100% dans quelques jours.
Je surveille les fichiers depuis un moment:
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 tous les jours. 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 un espace alloué d'une autre manière?
S'il y a une croissance invisible de l'espace disque, les fichiers supprimés constitueront probablement le coupable. 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 le permette. Dans certains cas, cela peut être utilisé en tant que ne manière élégante de nettoyer après vous-même - les plantages d'application n'empêcheront pas le nettoyage des fichiers temporaires.
Pour examiner 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 - ce n'est pas un problème en soi. Un seul fichier supprimé grossissant est un problème.
Un redémarrage devrait résoudre ce problème, mais si vous ne voulez pas redémarrer, vérifiez les applications impliquées (première colonne de la sortie lsof sortie) 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 les ignorer en tant que source d’utilisation importante du disque (mais vous devez quand même redémarrer le programme pour que les corrections de bogues s’appliquent).
Les fichiers de /dev/shm sont des objets de mémoire partagée et n'occupent pas beaucoup d'espace sur le disque (un numéro d'inode 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.). Ceux-ci pourraient être volumineux, si vous avez une fenêtre de terminal ouverte avec beaucoup (et que je veux dire beaucoup ) de données en sortie.
Pour ajouter à l'excellente réponse de muru:
- df montre la taille sur le disque,
- et du indique la taille totale du contenu des fichiers.
Peut-être que ce que vous ne voyez pas avec est l'apparition de très nombreux petits fichiers ... (regardez dans la dernière colonne de df -i et voyez si le nombre d'inodes (c'est-à-dire de fichiers) augmente beaucoup plus de temps aussi)
Si vous avez, disons, 1'000'000 (1 million) de minuscules fichiers d'un octet, du comptera cela comme un total de 1'000'000 octets, disons de 1 Mo (... puristes, s'il vous plaît ne pas reculer
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 être de 16 Ko (!),
- 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 ...), de sorte que votre 1 octet de données occupera au moins 1 bloc.
Ainsi, un million de fichiers d'un octet occuperont 1'000'000'000 * size_of_a_block 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 d'utilisation de disque pour 1 million "1 octet" " des dossiers.
Si vous avez des blocs de 1024 octets et 256 octets supplémentaires en taille d'inode, vos 1 000 000 fichiers seront rapportés à environ 1 Mo par du, mais compteront pour environ 1,25 Go sur le disque (vu par df)! (ou même 2 Go si chaque inode doit aussi être sur 1 bloc de disque dédié ... Je ne sais pas si c'est le cas)