df dit que le disque est plein, mais il ne l'est pas.

Question

df dit que le disque est plein, mais il ne l'est pas.

Demandé el 24 de Septembre, 2011: Quand la question a-t-elle été
229916 affichage: Nombre de visites la question a
5 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

Sur un serveur virtualisé exécutant Ubuntu 10.04, df signale ce qui suit :

# 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 indique que /dev/sda1, monté sur /, a une capacité de 7,4 gigaoctets, dont seulement 7,0 gigaoctets sont utilisés, mais il signale que / est plein à 100 % ; et 2.) je peux créer des fichiers sur /, il lui reste donc 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é sur /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) ultérieure.

Demandé el 24 de Septembre, 2011 par Chris

0 votes

Merci à tous pour les réponses utiles. Je ne peux pas créer de fichiers en tant qu'utilisateur normal, il semble donc que ce soit le tampon de 5 % qui empêche la catastrophe. Il ne me reste plus qu'à comprendre pourquoi le disque est plein (j'ai un peu peur que quelque chose de malveillant se passe car aucun des fichiers journaux ne prend autant de place et il n'y a pas beaucoup de logiciels installés, juste un simple serveur LAMP)...

Commenté el 25 de Septembre, 2011 par Chris

3 votes

Le premier endroit où je regarderais est /tmp. Une autre possibilité est que vous ayez un fichier supprimé auquel un programme en cours d'exécution s'accroche. Je pense que vous pouvez exécuter 'lsof | grep deleted' en tant que root pour les trouver.

Commenté el 29 de Septembre, 2011 par wows

Answer 1

5 Réponses

Answer 2

166voto

mkomitee Points 1531

Il est possible qu'un processus ait ouvert un fichier volumineux qui a été supprimé depuis. Vous devrez tuer ce processus pour libérer 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 le vérifier avec sudo lsof +L1

Répondu el 27 de Septembre, 2011 par mkomitee (1531 Points )

14 votes

Ça a résolu le mystère pour moi. J'ai supprimé un gros fichier journal de uwsgi sans redémarrer le service. Lorsqu'on l'interroge df -ah J'ai un disque plein, mais du -sh / dit que je devrais avoir de l'espace libre. Après avoir redémarré uwsgi, j'ai beaucoup d'espace libre !

Commenté el 15 de Octobre, 2014 par krams

1 votes

J'avais 40G de journaux bloqués dans les limbes et lsof +L1 m'a permis de voir ce qui s'était passé ;-) Tout ce que j'avais à faire était de redémarrer le service.

Commenté el 7 de Mai, 2018 par Bomlin

0 votes

J'ai remarqué que cela se produit fréquemment à cause de la journalisation personnalisée ajoutée à une configuration de services donnée en combinaison avec logrotate. Par exemple, j'utilise Unbound (sous Ubuntu). La journalisation s'effectue par défaut sur syslog. Mais j'ai fait en sorte que le mien utilise son propre fichier journal. Celui-ci est mis en rotation via logrotate. Dans le cas d'Unbound, logrotate a besoin de unbound-control log_reopen dans le fichier logrotate pour qu'il libère l'ancien journal ouvert (supprimé). Vous pouvez également choisir de simplement redémarrer le service. réf : lists.nlnetlabs.nl/pipermail/unbound-users/2019-July/

Commenté el 10 de Juin, 2020 par Mark Allanson

Answer 3

62voto

David Schwartz Points 31009

5% (par défaut) du système de fichiers est réservé aux cas où le système de fichiers se remplit afin d'é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 doivent gérer des fichiers dans ce système de fichiers, les choses vont se casser. Un démon courant de ce type est named . Un autre est ntpd .

Répondu el 24 de Septembre, 2011 par David Schwartz (31009 Points )

1 votes

A la question de POURQUOI votre disque est plein, 7G n'est pas vraiment beaucoup d'espace. Vous semblez aussi avoir 何事も sous une partition/un système de fichiers ( / ). Ceci est généralement considéré comme une mauvaise chose (parce que si quelque chose se dérègle / se remplit, et c'est la fin du monde) mais les distributions Linux persistent à le faire parce que c'est "plus simple". Je commencerais par regarder dans /var (esp. /var/log ) pour les fichiers journaux volumineux. du -hs / (en tant que root) vous aidera à trouver les plus grands répertoires et vous indiquera éventuellement ce qui doit être nettoyé.

Commenté el 27 de Septembre, 2011 par voretaq7

Answer 4

46voto

Chris Points 11

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

df -i

Répondu el 24 de Septembre, 2011 par Chris (11 Points )

Answer 5

29voto

mattmc3 Points 6768

La plupart des systèmes de fichiers Linux (ext3, ext4) réservent 5 % de l'espace à l'usage exclusif de l'utilisateur root.

Vous pouvez le constater avec, par exemple

dumpe2fs /dev/sda1 | grep -i reserved

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

tune2fs -m 0 /dev/sda1

0 dans cette commande représente le pourcentage de la taille du disque, il est donc préférable de laisser au moins 1%.

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

Répondu el 25 de Septembre, 2011 par mattmc3 (6768 Points )

0 votes

Merci beaucoup, cela explique pourquoi je ne pouvais pas utiliser les 50 Go restants de mon disque externe de 1 To.

Commenté el 27 de Septembre, 2021 par Martin Pecka

Answer 6

17voto

Robert Lujo Points 241

En plus des causes déjà suggérées, dans certains cas, il peut également s'agir des causes suivantes :

un disque différent est monté "par-dessus" le dossier existant qui est plein de données
du calculera la taille dépensée du disque monté et df montrera la taille réellement dépensée.
solution : (quand c'est possible) démonter tous les disques non racine et vérifier la taille avec du -md 1 à nouveau. Réglez la situation en déplaçant caché à un autre endroit ou le monter à un autre endroit.

Répondu el 23 de Octobre, 2014 par Robert Lujo (241 Points )

0 votes

Comment trouver les points de montage autrement que par df ?

Commenté el 4 de Septembre, 2015 par Doug Brown

1 votes

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

Commenté el 7 de Septembre, 2015 par Robert Lujo

df dit que le disque est plein, mais il ne l'est pas.

Réponses

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

df dit que le disque est plein, mais il ne l'est pas.

Réponses

Questions connexes

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: