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

Sur un serveur virtualisé exécutant Ubuntu 10.04, df rapporte 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 / qu'il est plein à 100%; et 2.) Je peux créer des fichiers sur / afin qu'il y ait clairement un espace disponible.

Peut-être pertinent est que le répertoire / www est un lien symbolique vers / home / www, qui se trouve sur une partition différente (/ dev / sda3, monté sur / home).

Quelqu'un peut-il offrir 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.

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 encore supprimés et connus sont connus de lsof et marqués comme (supprimés) dans la sortie de lsof.

Vous pouvez vérifier cela avec sudo lsof +L1

5% (par défaut) du système de fichiers est réservé aux cas où le système de fichiers se remplit pour éviter des problèmes graves. Votre système de fichiers est plein. Rien de catastrophique ne se produit à cause de la mémoire tampon de 5% - root est autorisé à utiliser cette mémoire 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 les fichiers de ce système de fichiers, les choses se casseront. Un tel démon est commun named. Un autre est ntpd.

Vous êtes peut-être en rupture d'inodes. Vérifiez l'utilisation d'inode avec cette commande:

df -i

La plupart des systèmes de fichiers Linux réservent 5% d’espace pour l’utilisation exclusive de l’utilisateur root.

Vous pouvez voir cela 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 semble continuer à fonctionner correctement, à supposer que tous les processus soient exécutés en tant que «root».

J'avais ce problème et j'étais déconcerté par le fait que la suppression de plusieurs fichiers volumineux n'améliorait pas la situation (je ne connaissais pas le tampon de 5%).

Depuis la racine, parcourez les plus grands répertoires révélés en effectuant de manière répétitive: -

du -sh */ 

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

avec lequel j'ai tronqué

:>lighttpd.error.log

du coup df -h était utilisé à 48%!

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

• un autre disque 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 passé
• solution: (si possible) démontez tous les disques non-root et vérifiez à du -md 1nouveau la taille . Corrigez la situation en déplaçant le dossier caché dans un autre emplacement ou en effectuant un montage dans un autre emplacement.

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

Oh. Et ext3 et ses dérivés réservent un pourcentage (valeur par défaut de 5%) au système de fichiers pour 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. Donc, la partie réservée empêche cela.

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

apt-get install -f
sudo apt-get clean

Et vide ta corbeille

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

Si votre partition est btrfs, il peut y avoir un sous-volume prenant de la place. 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>en supprimer un. Assurez-vous de ne pas supprimer celui qui est monté par défaut.