Je ne pense pas qu'un "outil de visualisation d'espace disque" puisse vous aider dans ce cas: l'espace occupé et visible par ces outils est identique à celui visible du, seuls ces outils le font plus en détail. Mais l'outil ne signalerait toujours que les 8-10 Go que vous savez déjà utilisés, et non le lieu où se trouvent ces vingt gigaoctets supplémentaires qui sont "manquants en action".
Une explication possible d'un espace "en train de disparaître" de telles proportions est qu'il se trouve dans un (ou plusieurs) fichier (s) supprimé (s ) .
Si vous ouvrez un fichier sous Unix et que, même s'il est toujours ouvert, vous le supprimez (il le dissocie), il existera toujours, mais il ne sera visible que par le processus qui conserve son descripteur de fichier. le descripteur.
C'est un excellent moyen de gérer les fichiers temporaires.
Malheureusement, si le fichier temporaire fuit et que des données y sont ajoutées en permanence, sans jamais fermer ni recréer le fichier, beaucoup d’espace disque risque de "disparaître".
En tant que root, essayez:
ls -la /proc/*/fd/* | grep deleted
Les noms de fichier et les ID de processus vous indiqueront quels processus conservent de l’espace "non lié".
Si vous pouvez le faire, bien sûr, un redémarrage aura le même effet plus rapidement. Et certains processus sont tellement imbriqués dans le système qu'il est préférable de les redémarrer plutôt que de les arrêter et de gérer tous les autres processus et services dépendants .
Par exemple, sur ma machine, j'ai environ 25 fichiers de ce type, et celui-ci
lrwx------ 1 root root 64 May 9 07:45 /proc/732/fd/8 -> /tmp/vmware-root/vmware-usbarb-732.log (deleted)
Je sais que, parfois, la taille varie de plusieurs mégaoctets. Fonctionnement
vmware-usbarbitrator --kill
vmware-usbarbitrator
peut libérer de zéro à 100 millions d’espace en fonction de sa durée de fonctionnement et de la quantité de ressources que j’ai utilisée vmplayer.
Automatiser le chèque
Un moyen de vérifier quels fichiers sont très volumineux serait de vérifier leur taille: la plupart des fichiers non liés ne contiennent que quelques octets.
Cette méthode utilise wc, ce qui est très inefficace; probablement, ouvrir le fichier, chercher SEEK_ENDet retourner la valeur de ftell()serait beaucoup, beaucoup plus rapide (surtout sur les gros fichiers). Mais il faudrait compiler un petit utilitaire pour le faire.
for i in $( ls -la /proc/*/fd/* 2>/dev/null \
| grep deleted \
| sed -e 's/.*\(\/proc\S*\) -.*/\1/g' ); do
wc -c $i | tr "\n" "="; readlink $i
done | grep -v "^0 " | sort -rn
Cela utilise un moyen (espérons-le) portable de lister les fichiers virtuels de tous les fichiers supprimés et de les lire wc. Ensuite, pour chaque fichier, lit le lien symbolique. Les fichiers de longueur nulle sont ignorés pour éviter l'encombrement.
Sur mon système fraîchement démarré, cela me donne
217032 /proc/812/fd/9=/var/run/nscd/dbMn7Auu (deleted)
217032 /proc/812/fd/8=/var/run/nscd/dbMn7Auu (deleted)
3278 /proc/2357/fd/3=/tmp/vmware-root/vmware-apploader-2327.log (deleted)
2257 /proc/2422/fd/7=/tmp/vmware-root/vmware-authdlauncher-2418.log (deleted)
Je sais donc qu’il nscds’appuie sur 400 Ko d’espace invisible (cela ne change pas si je redémarre nscd; il s’agit donc probablement d’une zone de travail qui ne s’agrandit pas… beaucoup. Rien ne m’empêche de suivre le processus, bien que).
Il serait également facile de sauvegarder le code ci-dessus dans un petit utilitaire et de l'exécuter cron, en supprimant toutes les valeurs inférieures à (par exemple) 500 Mo, mais l'envoi d'un courrier électronique à l'administrateur devrait éventuellement faire apparaître quelque chose.
dusortie: Vous exécutez cette commande en tant queroot, n'est-ce pas?!