Comment libérer l'utilisation d'inodes?
J'ai un lecteur de disque où l'utilisation d'inode est de 100% (en utilisant la commande df -i). Cependant, après la suppression substantielle de fichiers, l'utilisation reste à 100%.
Quelle est la bonne façon de le faire alors?
Comment est-il possible qu'un lecteur de disque utilisant moins d'espace disque puisse utiliser davantage d'Inode qu'un lecteur de disque utilisant davantage d'espace disque?
Est-il possible, si je compressais beaucoup de fichiers, cela réduirait le nombre d'inodes utilisés?
Il est assez facile pour un disque d'avoir un grand nombre d'inodes utilisés même si le disque n'est pas très plein.
Un inode est alloué à un fichier. Par conséquent, si vous avez des milliards de fichiers, tous les octets d'un octet, vous manquerez d'inodes pendant de nombreuses années.
Il est également possible que la suppression de fichiers ne réduise pas le nombre d'inodes si les fichiers comportent plusieurs liens physiques. Comme je l'ai dit, les inodes appartiennent au fichier, pas l'entrée du répertoire. Si deux entrées de répertoire sont associées à un fichier, la suppression d'une ne libérera pas l'inode.
En outre, vous pouvez supprimer une entrée de répertoire, mais si le fichier est toujours ouvert sur un processus en cours, l'inode ne sera pas libéré.
Mon conseil initial serait de supprimer tous les fichiers que vous pouvez, puis de redémarrer la boîte pour vous assurer qu'il ne reste aucun processus maintenant les fichiers ouverts.
Si vous faites cela et que vous avez toujours un problème, faites-le nous savoir.
À propos, si vous recherchez des répertoires contenant beaucoup de fichiers, ce script peut vous aider:
#!/bin/bash
# count_em - count files in all subdirectories under current directory.
echo 'echo $(ls -a "$1" | wc -l) $1' >/tmp/count_em_$$
chmod 700 /tmp/count_em_$$
find . -mount -type d -print0 | xargs -0 -n1 /tmp/count_em_$$ | sort -n
rm -f /tmp/count_em_$$
Si vous êtes très malchanceux, vous avez utilisé environ 100% de tous les inodes et vous ne pouvez pas créer le scipt. Vous pouvez le vérifier avec df -ih.
Alors cette commande bash peut vous aider:
Sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n
Et oui, cela prendra du temps, mais vous pouvez localiser le répertoire contenant le plus de fichiers.
Ma situation était que je n'avais plus d'inodes et que j'avais déjà effacé tout ce que je pouvais.
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 942080 507361 11 100% /
Je suis sur une Ubuntu 12.04LTS et ne pouvais pas supprimer les anciens noyaux Linux qui prenaient environ 400 000 inodes car apt était cassé à cause d’un paquet manquant. Et je ne pouvais pas installer le nouveau package car je n'avais plus d'inodes et j'étais donc bloqué.
J'ai fini par supprimer manuellement quelques vieux noyaux Linux pour libérer environ 10 000 inodes.
$ Sudo rm -rf /usr/src/linux-headers-3.2.0-2*
Cela suffisait pour me laisser installer le paquet manquant et réparer mon apt
$ Sudo apt-get install linux-headers-3.2.0-76-generic-pae
puis supprimez le reste des anciens noyaux Linux avec apt
$ Sudo apt-get autoremove
les choses vont beaucoup mieux maintenant
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 942080 507361 434719 54% /
Ma solution:
Essayez de trouver s'il s'agit d'un problème d'inodes avec:
df -ih
Essayez de trouver les dossiers racine avec un grand nombre d'inodes:
for i in /*; do echo $i; find $i |wc -l; done
Essayez de trouver des dossiers spécifiques:
for i in /src/*; do echo $i; find $i |wc -l; done
S'il s'agit d'en-têtes Linux, essayez de supprimer le plus ancien avec:
Sudo apt-get autoremove linux-headers-3.13.0-24
Personnellement, je les ai déplacés vers un dossier monté (car pour moi la dernière commande a échoué) et j'ai installé la dernière avec:
Sudo apt-get autoremove -f
Cela a résolu mon problème.
J'ai eu le même problème, corrigé en supprimant le répertoire sessions de php
rm -rf /var/lib/php/sessions/
Il peut être sous /var/lib/php5 si vous utilisez une version plus ancienne de PHP.
Recréez-le avec la permission suivante
mkdir /var/lib/php/sessions/ && chmod 1733 /var/lib/php/sessions/
L'autorisation par défaut pour le répertoire sur Debian a montré drwx-wx-wt (1733)
Nous avons constaté cela sur un compte HostGator (qui impose des limites d'inode à tous leurs hébergements) à la suite d'une attaque de spam. Il a laissé un grand nombre d’enregistrements de file d’attente dans /root/.cpanel/comet. Si cela se produit et que vous constatez que vous n'avez pas d'inodes libres, vous pouvez exécuter cet utilitaire cpanel via Shell:
/usr/local/cpanel/bin/purge_dead_comet_files
Nous avons rencontré un problème similaire récemment. Dans le cas où un processus fait référence à un fichier supprimé, l'inode ne doit pas être publié, vous devez donc vérifier lsof /, et arrêter/redémarrer le processus pour libérer les inodes.
Corrigez-moi si je me trompe ici.
Comme indiqué précédemment, le système de fichiers peut manquer d'inodes, s'il y a beaucoup de petits fichiers. J'ai fourni des moyens de trouver des répertoires contenant la plupart des fichiers ici .
eaccelerator pourrait être à l'origine du problème car il compile PHP en blocs ... J'ai eu ce problème avec un serveur Amazon AWS sur un site très chargé. Libérez Inodes en supprimant le cache eaccelerator dans/var/cache/eaccelerator si le problème persiste.
rm -rf /var/cache/eaccelerator/*
(ou quel que soit votre répertoire cache)
Vous pouvez utiliser RSYNC pour SUPPRIMER le grand nombre de fichiers
rsync -a --delete blanktest/ test/
Créez un dossier blanktest contenant 0 fichiers et la commande synchronisera vos dossiers de test avec un grand nombre de fichiers (j'ai supprimé près de 5 millions de fichiers à l'aide de cette méthode).
Merci à http://www.slashroot.in/which-is-the-fastest-method-tof-delete-files-in-linux
Si vous utilisez un menu fixe, supprimez toutes les images. Ils ont utilisé beaucoup d'espace ....
Arrêtez tous les conteneurs
docker stop $(docker ps -a -q)
Supprimer tous les conteneurs
docker rm $(docker ps -a -q)
Supprimer toutes les images
docker rmi $(docker images -q)
Fonctionne pour moi