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

58

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.

linux ubuntu partition

— Chris
source

Merci à tous pour les réponses utiles. Je ne peux pas créer de fichiers en tant qu'utilisateur normal, il apparaît donc que c'est la mémoire tampon de 5% qui empêche une catastrophe. Maintenant, je dois juste comprendre pourquoi le disque est plein (je crains un problème de malice, car aucun fichier journal ne prend autant d’espace et il n’ya pas beaucoup de logiciels installés, juste un simple serveur LAMP) ...

— Chris

3

Le premier endroit où je chercherais est / tmp. Une autre possibilité est que vous ayez un fichier supprimé qu'un programme en cours conserve. Je pense que tu peux courir 'lsof | grep supprimé 'en tant que root pour les trouver.

— Scott

103

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

— mkomitee
source

8

C'est résolu le mystère pour moi. J'ai supprimé un fichier journal volumineux de uwsgi sans redémarrer le service. Lorsqu’on df -ahme pose une question , le disque est plein, mais du -sh /indique que je devrais avoir de l’espace libre. Après avoir redémarré uwsgi, j'ai eu beaucoup d'espace libre!

— Fabio Montefuscolo

J'avais 40G de journaux bloqués dans les limbes et lsof + L1 m'a donné la vision aux rayons X pour voir ce qui s'était passé ;-) Tout ce que j'avais à faire, c'était de redémarrer le service.

— PJ Brunet

46

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.

— David Schwartz
source

1

À la question de savoir pourquoi votre disque est plein, la 7G n’a vraiment pas beaucoup d’espace. Vous semblez également avoir tout vidé sous une même partition / système de fichiers ( /). Ceci est généralement considéré comme une mauvaise chose (parce que si quelque chose se passe mal se /remplit et que le monde se termine), mais les distributions Linux persistent à le faire parce que c'est "plus simple". Je commencerais par chercher /var(surtout /var/log) d'énormes fichiers journaux. du -hs /(en tant que root) vous aidera à trouver les plus gros répertoires et éventuellement vous indiquera ce qui doit être nettoyé.

— voretaq7

35

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

df -i

— Clifford Ilkay
source

17

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».

— David Goodwin
source

8

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%!

— zzapper
source

14

Cela devrait vraiment se terminer par "... alors j'ai mis en place la rotation des journaux."

— hayalci

hayalci: a constaté que la logrotation pointait vers le mauvais répertoire.

— Zzapper

8

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.

— Robert Lujo
source

comment trouvez-vous des points de montage autres que df?

— Hogan

@Hogan: peut-être qu'appeler "mount" ou "cat / etc / fstab" pourrait vous aider?

— Robert Lujo

5

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.

— mailq
source

Peut-être aussi qu'il n'a plus d'inodes libres. Exécutez 'df -i' pour obtenir l'utilisation d'inodes.

— Andrew Case

Il n'a pas fourni d'informations que le disque est plein. Il pense seulement que le disque est plein. 100% de l'espace utilisé sans erreur est seulement "pratiquement plein".

— mailq

1

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

— banlieue
source

C’est un conseil général raisonnable sur la réduction de l’utilisation du disque, mais il n’aborde pas la question de savoir pourquoi df dit que le disque est plein alors que ce n’est pas le cas.

— Andrew Schulman

0

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

— Jude Zhu
source

0

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.

— utilisateur377486
source