Problème d'espace disque très étrange

Support Debian
#1

Bonjour,

Il m’arrive un truc bizarre sur un de mes serveurs : des dysfonctionnements apparaissent subitement (réception de mail notamment).
L’espace disque est correct :

~  df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/xvda1          20G    7,5G   12G  40% /
udev                10M       0   10M   0% /dev
tmpfs              413M     42M  371M  11% /run
tmpfs              1,1G       0  1,1G   0% /dev/shm
tmpfs              5,0M       0  5,0M   0% /run/lock
tmpfs              1,1G       0  1,1G   0% /sys/fs/cgroup
tmpfs               24K       0   24K   0% /var/gandi
/dev/xvdb           69G     51G   16G  77% /home
/dev/loop0         976M    1,5M  924M   1% /tmp

Qd je me connecte en ssh j’ai néanmoins ce message indicatif :

zsh: locking failed for /root/.zsh_history: aucun espace disponible sur le périphérique: reading anyway

Dubitatif et ne trouvant rien qui justifie cette perte d’espace disque, j’augmente la taille de la partition racine (c’est un VPS), je redémarre et ça refonctionne.

Le soucis c’est que c’est la 2e fois que le problème survient.

Qu’est-ce qui pourrait occuper de la place sur la partition racine de façon cachée et comment le débusquer ?

#2

C’est peut être juste le redémarrage qui fonctionne, et pas le redimensionnement ?

Tu n’as pas fourni le resultat de mount, mais la prochaine fois que tu as le message avec zsh, avant de redémarrer, vérifie avec mount que ta partition racine ne s’est pas remontée en lecture seule suite à une erreur (option remount-ro du mount):
comme ton /tmp et ton /run sont en ramdisk, il est possible que ton serveur continuer à tourner sans problème dans cet état malgré le ro de /, car plus besoin d’y écrire, à part pour les logs.

Un moyen de vérifier ça quand l’erreur n’est pas là serait de regarder s’il y a des trous dans un log qui parle tout le temps, comme syslog:
si tu vois que le log s’arrète à un moment et reprend longtemps aprés, genre quand tu as redémarré, c’est qu’il n’a pas pu écrire le log pendant la période de trou.

Et sinon, as tu fait un fsck sur la partition ?

#3

Bonjour,

Que retourne df -ih ? Je t’invite à te documenter un peu sur les inodes, même si ce n’est pas forcément ça.

#4

En effet la piste de l’épuisement des inodes disponibles est à vérifier si la création de nouveaux fichiers échoue (mais pas l’écriture dans un fichier existant).
Quel est le type de système de fichiers de la racine (ajouter l’option -T à df) ?
Si c’est ext4, le nombre d’inodes disponibles est fixé lors de la création et n’est pas augmenté par l’agrandissement du système.
Si c’est btrfs, sa gestion de l’espace libre est particulière et les valeurs affichées par df ne sont pas forcément justes.

Ni l’un ni l’autre n’est en ramdisk (périphérique bloc en mémoire).
/run est en tmpfs (système de fichiers en mémoire virtuelle) comme c’est l’usage.
/tmp est en loop donc probablement dans un fichier image sur disque (ce dont je ne vois pas l’intérêt).

Hors cas très particulier, l’usage d’un ramdisk pour un système de fichiers est devenu complètement obsolète depuis l’introduction de tmpfs qui offre de nombreux avantages :

  • pas besoin de formater
  • beaucoup plus rapide
  • n’alloue que la quantité de mémoire réellement occupée par le contenu à la hausse et à la baisse (le pilote ramdisk supportait l’option discard mais cela ne libère pas l’espace mémoire déjà alloué)
  • facile à redimensionner
  • peut utiliser le swap si nécessaire
#5

+1 pour les inodes
Si tu as un dossier contenant beaucoup de petits fichiers, commence par les supprimer.

#6

Pour tmp, j’avais mal vu le loop, mais quand je dis ramdisk, je pense filesystem en mémoire, donc j’y inclus le tmpfs, c’est ça que je voulais dire, désolé de l’abus de langage.
Ce que je voulais dire aussi, c’est que même avec / en ro, les écritures qui pourraient faire planter les services n’ecrivent pas sur / avec /tmp et /run séparés.

#7

Merci pour vos différentes réponses !
Effectivement la piste des inodes me semble intéressante.
Il m’indique 67% d’utilisation après le redémarrage de ce matin et la partition est en ext4
Par contre je ne vois pas trop comment faire pour m’en sortir car supprimer des petits fichiers, OK, mais comment je les trouves, et comment être sûr qu’ils ne sont pas utiles ?

Pour le /tmp il est en effet sur une partition séparée pour bénéficier du paramètre nodev.

#8

67%, ça laisse de la marge. Il faudra regarder lorsque le problème se produira à nouveau pour confirmer ou infirmer que cela vient de là.

Mais pourquoi en loop si c’est une partition ?

#9

Comme le dit PascalHambourg , il y a de la marge, du coup faudrait effectivement voir au moment où tu as le soucis.

Tu peux utiliser du pour t’afficher l’occupation en inodes des éléments du répertoire courant :

du -sh --inodes /

Après y a plus qu’a descendre petit à petit dans les arborescences en renouvelant la commande à chaque fois.

#10

Pour le paramètre loop, c’est une bonne question ! J’ai du trouver ça sur un tuto il y a longtemps et je l’ai mis sans en saisir le sens (ça vous arrive vraiment jamais à vous ? :smiley: ).
Je vais me renseigner et le virer si besoin.

Pour les inodes, aujourd’hui j’en suis à 68%, donc légère augmentation.

Grace à la commande
find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n

… j’ai pu repérer le répertoire gourmand : /var/lib/php/sessions
J’ai mis en place un cron qui fait le nettoyage régulièrement.
Je pense que mon soucis va être résolu :slight_smile:

Merci pour vos retours bien utiles en attendant :slight_smile:

#11

Non, jamais. Je n’applique pas une instruction que je ne comprends pas. Si le tutoriel n’explique pas assez, je vais systématiquement chercher des informations supplémentaires dans les pages de manuel ou autres documentations.

Quel est l’âge des fichiers les plus anciens ?

#12

Normalement y en a un, par contre il ne fonctionne pas forcément : https://inios.fr/article137/sessions-php-sur-lxc-et-debian-9