supprimer des fichiers mais l'espace disque est encore plein

Deux choses pourraient se produire ici.

Premier , votre système de fichiers a réservé un espace que seul root peut utiliser en écriture, afin que les processus critiques du système ne soient pas interrompus lorsque les utilisateurs normaux manquent d'espace disque. C'est pourquoi vous voyez 124G de 130G utilisés, mais zéro disponible. Peut-être que les fichiers que vous avez supprimés ont ramené l'utilisation à ce point, mais pas en dessous du seuil pour les utilisateurs normaux.

Si c'est votre situation et que vous êtes désespéré, vous pouvez peut-être modifier la quantité d'espace réservée pour root. Pour le réduire à 1% (la valeur par défaut est 5%), votre commande serait

# tune2fs -m 1 /dev/sda3

Seconde , le système d'exploitation ne libère pas d'espace disque pour les fichiers supprimés qui sont encore ouverts. Si vous avez supprimé (disons) un des fichiers journaux d'Apache, vous devrez redémarrer Apache afin de libérer l'espace.

Si vous supprimez un fichier qui est utilisé par un processus, vous ne pouvez plus visualiser le fichier par ls. Le processus continue d'écrire dans ce fichier jusqu'à ce que vous l'arrêtiez.

Pour visualiser ces fichiers supprimés, il suffit d'exécuterlsof|grep delete.

2 autres façons d'obtenir le disque est plein problème :

1) caché sous un point de montage: linux affichera un disque plein avec des fichiers “cachés” sous un point de montage. Si vous avez des données écrites sur le disque et que vous montez un autre système de fichiers par dessus, linux note correctement l'utilisation du disque même si vous ne pouvez pas voir les fichiers sous le point de montage. Si vous avez des montages nfs, essayez de les démonter et regardez si quelque chose a été accidentellement écrit dans ces répertoires avant le montage.

2) fichiers corrompus: Je vois cela de temps en temps sur les transferts de fichiers de Windows à Linux via SMB. Un fichier ne parvient pas à fermer le descripteur de fichier et vous vous retrouvez avec un fichier de 4 Go de corbeille.

Cela peut être plus fastidieux à réparer, car vous devez trouver le sous-répertoire dans lequel se trouve le fichier, mais c'est facile à réparer car le fichier lui-même est facilement amovible. J'utilise la commande du et je fais une liste des sous-répertoires de la racine pour savoir où l'espace du fichier est utilisé.

cd /
du -sh ./*

Le nombre de répertoires de premier niveau est généralement limité, donc je mets le drapeau humainement lisible -h pour voir quel sous-répertoire est le plus utilisé.

Puis vous cd dans l'enfant à problème et répétez le processus pour tous les éléments qui s'y trouvent. Pour faciliter le repérage des grands éléments, nous modifions légèrement le du et le couplons avec un tri.

cd /<suspiciously large dir>
du -s ./* | sort -n

qui produit un résultat du plus petit au plus grand par taille d'octet pour tous les fichiers et répertoires

4 ./bin 
462220 ./Documents
578899 ./Downloads
5788998769 ./Grocery List

Une fois que vous avez repéré le fichier surdimensionné, vous pouvez généralement simplement le supprimer.

Vous pourriez découvrir quels sont les dossiers ouverts avec lsof. Il peut produire beaucoup de résultats, c'est pourquoi je me suis limité dans l'exemple ci-dessous aux lignes se terminant par un log :

# lsof | grep log$
rsyslogd 2109 syslog 0u unix 0xffff88022fa230c0 0t0 8894 /dev/log
rsyslogd 2109 syslog 1w REG 252,6 62393 26 /var/log/syslog
rsyslogd 2109 syslog 2w REG 252,6 113725 122 /var/log/auth.log
rsyslogd 2109 syslog 3u unix 0xffff88022fa23740 0t0 8921 /var/spool/postfix/dev/log
rsyslogd 2109 syslog 5w REG 252,6 65624 106 /var/log/mail.log
/usr/sbin 2129 root 2w REG 252,6 93602 38 /var/log/munin/munin-node.log
/usr/sbin 2129 root 4w REG 252,6 93602 38 /var/log/munin/munin-node.log
...

Si certains fichiers sont supprimés mais toujours utilisés par un processus quelconque, l'espace qu'ils occupent ne sera pas libéré. Dans ce cas, il faut soit relancer un processus qui utilise le fichier, soit annuler le fichier. Il est toujours préférable d'annuler ces fichiers plutôt que de les supprimer. Pour trouver les fichiers supprimés mais encore utilisés par un processus,

#lsof +L1

il faut donner l'identifiant du processus et le descripteur du fichier. Pour annuler les fichiers supprimés par le descripteur de fichier

#echo "" > /proc/$pid/fd/$fd
```.

Dans la plupart des cas, si nous supprimons un fichier journal, il ne voit plus le fichier par ls. Le processus continue d'écrire dans ce fichier jusqu'à ce que vous l'arrêtiez.

Tapez la commande

#lsof +L1

qui affichera la liste des fichiers qui contiennent de la mémoire avec citation supprimée.

Notez le pid ( Process id ) du fichier

Tuez le processus

#kill <pid>

La mémoire sera libérée par le processus

Vérifiez par la commande

#df -h

Problème réel observé dans la nature :

Assurez-vous que vous supprimez les fichiers réels et non les symlinks vers les fichiers. Cela peut être le cas pour les fichiers de log notamment.

En plus de ce qui a été expliqué, le problème pourrait être qu'il y a un autre point de montage du répertoire de fichiers supprimés sur un autre périphérique de disque attaché sur le même serveur. Vérifiez les montages actuels et les entrées de l'onglet F.