Qu'est-ce qui mange mon espace disque?


13

J'utilise Linux Mint 14 Nadia. La partition Linux a 10G. Lorsque le système démarre, dusignale une utilisation de 80%. Ensuite, l'utilisation augmente lentement jusqu'à atteindre 100% et le système devient inutilisable. (Cela peut arriver de l'ordre de jours ou de semaines). Après le redémarrage, l'utilisation est réinitialisée à 80%.

La chose la plus étrange de toutes est qu'elle dune montre aucun changement.

Voici la sortie de ces commandes (Windows et les partitions des disques externes sont élidés):

# --- Just after reboot ---

$ df -h     
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  7.3G  2.0G  80% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M  288K  437M   1% /run/shm
none            100M   12K  100M   1% /run/user

$ sudo du -x   -d1 -h /
186M    /opt
512M    /var
11M /sbin
556K    /root
1.3G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
60K /tmp
9.1M    /bin
4.0K    /srv
7.3G    /            # <-- note this


# --- After some time ---

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.8G  9.1G  199M  98% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            428M  292K  428M   1% /dev
tmpfs            88M  1.3M   87M   2% /run
none            5.0M     0  5.0M   0% /run/lock
none            437M   27M  411M   7% /run/shm
none            100M   28K  100M   1% /run/user

$  sudo du -x   -d1 -h /
186M    /opt
511M    /var
11M /sbin
556K    /root
1.4G    /home
613M    /lib
8.0K    /media
4.6G    /usr
16K /lost+found
111M    /boot
39M /etc
4.0K    /mnt
520K    /tmp
9.1M    /bin
4.0K    /srv
7.3G    /              # <-- note this

(Remarque: j'utilise l'hibernation. Après l'hibernation, l'utilisation reste la même, et après le redémarrage, elle est réinitialisée à 80%.)

Comment suivre ce qui mange l'espace?

J'ai lu cette question . Je suis toujours dans le noir. Comment savoir quel programme est responsable de ce comportement?

Après l'édition : je l' ai trouvé. L'espace est revendiqué par le journal du noyau, qui est vu par dmesg. Il se remplit car ma machine génère des erreurs au rythme de 5 par seconde. (Il est lié à ce bogue .) Laissez les futurs lecteurs ayant un problème similaire - remplir lentement l'espace disque invisible du- ne pas oublier d'essayer dmesgde rechercher la cause.


1
Je préfère ncdula plaine dupour trouver de gros fichiers | répertoires. Il analyse l’arborescence complète du répertoire avant de vous permettre de faire quoi que ce soit; vous voudrez peut-être lui passer un chemin spécifique (par exemple ncdu /varou même juste ncdu ~)
Blacklight Shining

Plusieurs réponses décentes déjà sur ce site.
Sparhawk

Réponses:


15

Exécution répétée de

sudo du -x   -d1 -h /

(dans l'arborescence des répertoires) devrait vous indiquer où l'espace est consommé. Cela explique probablement sans autre enquête quelle application est à l'origine de cela.

fichiers invisibles

Si dune montre pas ces fichiers, l'une des possibilités est la suppression des fichiers. Un fichier (ou plutôt: son nom c'est-à-dire son entrée dans un répertoire) peut être supprimé tant que le fichier est encore en cours d'utilisation. Tant qu'il y a un descripteur de fichier valide pointant sur ce fichier, il couvre l'espace sur le volume (s'il ne s'agit pas d'un fichier vide ...).

cat >file &
ls -l file
rm file
ls -l file
# PID of cat is 19834
ls -l /proc/19834/fd
lrwx------ 1 hl hauke 64 11. Feb 19:16 0 -> /dev/pts/0
l-wx------ 1 hl hauke 64 11. Feb 19:16 1 -> /crypto/home/hl/tmp/file (deleted)
lrwx------ 1 hl hauke 64 11. Feb 19:15 2 -> /dev/pts/0

Vous pouvez trouver ces fichiers avec find:

find /proc/ -mindepth 3 -maxdepth 3 \
-regex '/proc/[1-9][0-9]*/fd/[1-9][0-9]*' -type l -lname '*(deleted)' \
-printf '%p\n     %l\n' 2>/dev/null

Il peut s'agir d'un seul fichier énorme ou d'un tas de fichiers plus petits qui causent votre problème. Il y a maintenant environ 30 fichiers de ce type sur mon système (appartenant à seulement cinq processus). ls -lmontre la taille de ces fichiers mais il ne semble pas possible d'obtenir cette valeur find.

Après avoir tué le processus, l'espace redevient disponible pour le système de fichiers ( df).


Cela ne répond pas à ma question. dune signale aucun changement dans l'espace consommé: 7,3 G au début et 7,3 G après le temps écoulé. dfsignale 7.3G gratuit au démarrage et jusqu'à 10G au fil du temps. Je ne trouve pas le problème avec du.
Arry

@Arry En effet, j'ai lu trop vite.
Hauke ​​Laging

8

Utilisez quelque chose comme

lsof -s | grep deleted | sort -k 8

pour voir quels processus gardent ouverts les fichiers supprimés. Les champs importants sont le deuxième (PID) et le huitième (troisième du dernier; la taille du fichier).

(Faites attention aux lignes dupliquées, ne les comptez pas deux fois. Vérifiez le PID et le chemin du fichier (dernier champ) ou le numéro d'inode (avant-dernier champ).)

Après cela, si vous trouvez un processus qui est probablement le coupable, nous pouvons voir comment le corriger.


Bonne suggestion, mais sur ma machine, cette commande ne signale que 2 fichiers supprimés ouverts avec une taille de 2k, ce qui est loin de 2.7G consommé au fil du temps par un processus errant.
Arry

C'était une excellente suggestion et cela m'a en effet aidé à résoudre un problème similaire à la question des parents. J'avais une énorme différence entre les commandes df et du. Dans mon cas spécifique, j'ai des journaux en rotation et un service qui transmet les journaux (journal de stockage dans cet exemple). Le service logstash gardait les journaux tournés ouverts, même lorsqu'ils étaient supprimés. Cela causait l'écart entre du et df. Une fois le service logstash redémarré, l'espace disque s'est affiché correctement.
aemus

J'ai eu un processus d'écriture d'un fichier à ajouter uniquement qui a augmenté indéfiniment et a finalement rempli mon disque. Ensuite, j'ai décidé de rm ce fichier mais le processus n'a pas fermé son descripteur de fichier, donc il était encore en quelque sorte utilisé. Le redémarrage du processus et la limitation de la taille AOF ont résolu mon problème.
aviggiano

Il convient de noter que cela nécessite des privilèges root. De plus, j'avais l'habitude sudo lsof -s | grep deleted | sort -hk7d'obtenir un tri numérique. Sans -h, le tri fait des choses lexicales drôles avec les nombres.
Derek

C'est incroyable. Up-voté
Techie

4
find / -size +10000k -print0 | xargs -0 ls -l -h

Utilisez-le pour trouver récursivement ce qui remplit plus de 10 Mo + de /(racine) et l'afficher avec beaucoup de détails avec ls -lin xargs. Si vous écrivez 1000000 (2 zéros supplémentaires), vous pouvez obtenir 1 Go + par exemple.

du / -h --max-depth=1 | sort -h

Vous pouvez également utiliser du et y creuser manuellement.


1

Chaque fois que cela se produit, je commence toujours ma concentration dans certains sous-répertoires. La structure FHS à laquelle adhèrent la plupart des distributions Linux est conçue dans cet esprit.

Regardez d'abord /var, suivi de /home.

$ sudo du -x -d1 -h /var  | sort -hr`

$ sudo du -x -d1 -h /home | sort -hr`

Vous pouvez également limiter votre attention aux sous-répertoires dans l'un de ces emplacements. Une fois que vous avez épuisé vos recherches, je passe généralement aux /rootsous-répertoires restants à /.

S'il s'agit d'une distribution basée sur Red Hat, le cache yumutilisé pour effectuer des mises à jour peut consommer une grande quantité d'espace. Vous pouvez utiliser cette commande pour l'effacer:

$ yum clean packages

D' autres distros que l' utilisation aptpeut faire quelque chose de similaire, apt-get clean.

J'exécuterais également cette commande en haut de votre /répertoire, cet emplacement peut parfois devenir la source des fichiers journaux parasites.

$ ls -la /

Portez une attention particulière aux fichiers dot! Des choses nommées .blah, par exemple.


1

timeshift mangeait mon disque.

sudo timeshift -delete--all

Récupéré 50 Go.


0

J'ai presque la même situation.

Dans mon cas, la raison en était VMware. L'un des autres VMwares sur la même machine, il a consommé les espaces disque. C'est pourquoi mon utilisation de l'espace disque était de 100%.

Après avoir supprimé des fichiers volumineux du VMware du voisin, cela fonctionne correctement.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.