web-dev-qa-db-fra.com

df indique que le disque est plein, mais ce n'est pas le cas

Sur un serveur virtualisé exécutant Ubuntu 10.04, df signale les éléments suivants:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7.4G  7.0G     0 100% /
none                  498M  160K  498M   1% /dev
none                  500M     0  500M   0% /dev/shm
none                  500M   92K  500M   1% /var/run
none                  500M     0  500M   0% /var/lock
none                  500M     0  500M   0% /lib/init/rw
/dev/sda3             917G  305G  566G  36% /home

Cela me laisse perplexe pour deux raisons: 1.) df dit que/dev/sda1, monté à /, a une capacité de 7,4 gigaoctets, dont seulement 7,0 gigaoctets sont utilisés, mais il indique/étant à 100% plein; et 2.) Je peux créer des fichiers sur/donc il reste clairement de l'espace.

Il est possible que le répertoire/www soit un lien symbolique vers/home/www, qui se trouve sur une partition différente (/ dev/sda3, montée dans/home).

Quelqu'un peut-il faire des suggestions sur ce qui pourrait se passer ici? Le serveur semble fonctionner sans problème, mais je veux m'assurer qu'il n'y a pas de problème avec la table de partition, les systèmes de fichiers ou autre chose qui pourrait entraîner une implosion (ou une explosion) plus tard.

linuxubuntupartition
61
Chris

Il est possible qu'un processus ait ouvert un fichier volumineux qui a depuis été supprimé. Vous devrez tuer ce processus pour libérer de l'espace. Vous pourrez peut-être identifier le processus en utilisant lsof. Sous Linux, les fichiers supprimés mais ouverts sont connus de lsof et marqués comme (supprimés) dans la sortie de lsof.

Vous pouvez vérifier cela avec Sudo lsof +L1

108
mkomitee

5% (par défaut) du système de fichiers est réservé aux cas où le système de fichiers se remplit pour éviter de graves problèmes. Votre système de fichiers est plein. Rien de catastrophique ne se produit à cause du tampon de 5% - root est autorisé à utiliser ce tampon de sécurité et, dans votre configuration, les utilisateurs non root n'ont aucune raison d'écrire dans ce système de fichiers.

Si vous avez des démons qui s'exécutent en tant qu'utilisateur non root mais qui ont besoin de gérer des fichiers dans ce système de fichiers, les choses vont s'arrêter. Un tel démon courant est named. Un autre est ntpd.

46
David Schwartz

Vous n'avez peut-être plus d'inodes. Vérifiez l'utilisation des inodes avec cette commande:

df -i
35
Clifford Ilkay

La plupart des systèmes de fichiers Linux réservent 5% d'espace pour être utilisé uniquement par l'utilisateur root.

Vous pouvez le voir avec par exemple

dumpe2fs /dev/sda1 | grep -i reserved

Vous pouvez modifier le montant réservé en utilisant:

tune2fs -m 0 /dev/sda1

Dans la plupart des cas, le serveur continuera de fonctionner correctement - en supposant que tous les processus sont exécutés en tant que "root".

17
David Goodwin

En plus des causes déjà suggérées, dans certains cas, il pourrait également être le suivant:

  • n disque différent est monté "sur" le dossier existant qui est plein de données
  • du calculera la taille dépensée du disque monté et df montrera vraiment dépensé
  • solution: (si possible) démontez tous les disques non root et vérifiez la taille avec du -md 1 encore. Corrigez la situation en déplaçant le dossier caché vers un autre endroit ou montez sur un autre endroit.
10
Robert Lujo

J'ai eu ce problème et j'ai été déconcerté par le fait que la suppression de divers fichiers volumineux n'a pas amélioré la situation (ne connaissait pas le tampon de 5%) de toute façon, en suivant quelques indices ici

De la racine parcouru les plus grands répertoires révélés en faisant de façon répétitive: -

du -sh */

jusqu'à ce que je vienne un répertoire pour les fichiers journaux du serveur Web qui avait des journaux absolument massifs

avec laquelle j'ai tronqué

:>lighttpd.error.log

df -h était soudainement utilisé à 48%!

9
zzapper

df -h arrondit les valeurs. Même les pourcentages sont arrondis. Omettez le -h et vous voyez des différences plus fines.

Oh. Et ext3 et dérivés réservent un pourcentage (par défaut 5%) pour le système de fichiers pour exactement cette constellation problématique. Si votre système de fichiers racine est vraiment plein (0 octet restant), vous ne pouvez pas démarrer le système. Ainsi, la partie réservée empêche cela.

5
mailq

J'ai fait une grosse mise à jour de plusieurs bibliothèques et il y avait beaucoup de bibliothèques inutiles et de fichiers temporels, donc je libère de l'espace dans le dossier "/" en utilisant:

apt-get install -f
Sudo apt-get clean

Et vide tes poubelles

1
aburbanol

Si votre partition est btrfs, il peut y avoir un sous-volume prenant de l'espace. Un système de fichiers btrfs peut avoir plusieurs sous-volumes, dont un seul est monté. Vous pouvez utiliser btrfs subvolume list <dir> pour répertorier tous les sous-volumes et btrfs subvolume delete <dir>/<subvolume> pour en supprimer un. Assurez-vous de ne pas supprimer celui qui est monté par défaut.

0
user377486

vérifiez le/lost + found, j'avais un système (centos 7) et une partie du fichier dans le/lost + found a mangé tout l'espace

0
Jude Zhu