¿Cómo liberar el uso de Inode?

Tengo una unidad de disco donde el uso del inodo es 100% (usando el df -icomando). Sin embargo, después de eliminar archivos sustancialmente, el uso sigue siendo del 100%.

¿Cuál es la forma correcta de hacerlo entonces?

¿Cómo es posible que una unidad de disco con menos uso de espacio en disco pueda tener un mayor uso de Inode que una unidad de disco con mayor uso de espacio en disco?

¿Es posible si comprimo muchos archivos que reducirían el recuento de inodos utilizados?

Es bastante fácil para un disco tener una gran cantidad de inodos utilizados incluso si el disco no está muy lleno.

Se asigna un inodo a un archivo, por lo que, si tiene miles de millones de archivos, todos de 1 byte cada uno, se quedará sin inodos mucho antes de quedarse sin disco.

También es posible que eliminar archivos no reduzca el recuento de inodos si los archivos tienen múltiples enlaces duros. Como dije, los inodes pertenecen al archivo, no a la entrada del directorio. Si un archivo tiene dos entradas de directorio vinculadas, eliminar una no liberará el inodo.

Además, puede eliminar una entrada de directorio pero, si un proceso en ejecución todavía tiene el archivo abierto, el inodo no se liberará.

Mi consejo inicial sería eliminar todos los archivos que pueda, luego reiniciar el cuadro para asegurarse de que no quedan procesos que mantengan los archivos abiertos.

Si hace eso y aún tiene un problema, infórmenos.

Por cierto, si está buscando los directorios que contienen muchos archivos, este script puede ayudarlo:

#!/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 tiene mala suerte, ha utilizado aproximadamente el 100% de todos los inodos y no puede crear el scipt. Puedes verificar esto con df -ih.

Entonces este comando bash puede ayudarte:

sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

Y sí, esto llevará tiempo, pero puede ubicar el directorio con la mayoría de los archivos.

Mi situación era que me había quedado sin inodes y ya había eliminado todo lo que podía.

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361     11  100% /

Estoy en un Ubuntu 12.04LTS y no pude eliminar los viejos núcleos de Linux que ocupaban alrededor de 400,000 inodes porque apt estaba roto debido a la falta de un paquete. Y no pude instalar el nuevo paquete porque no tenía inodos, así que estaba atascado.

Terminé eliminando algunos viejos núcleos de Linux a mano para liberar alrededor de 10,000 inodes

$ sudo rm -rf /usr/src/linux-headers-3.2.0-2*

Esto fue suficiente para luego permitirme instalar el paquete que falta y arreglar mi apt

$ sudo apt-get install linux-headers-3.2.0-76-generic-pae

y luego elimine el resto de los viejos núcleos de Linux con apt

$ sudo apt-get autoremove

Las cosas están mucho mejor ahora

$ df -i
Filesystem     Inodes  IUsed  IFree IUse% Mounted on
/dev/sda1      942080 507361 434719   54% /

Mi solución:

Intenta encontrar si este es un problema de inodes con:

df -ih

Trate de encontrar carpetas raíz con gran cantidad de inodos:

for i in /*; do echo $i; find $i |wc -l; done

Intenta encontrar carpetas específicas:

for i in /src/*; do echo $i; find $i |wc -l; done

Si se trata de encabezados de Linux, intente eliminar el más antiguo con:

sudo apt-get autoremove linux-headers-3.13.0-24

Personalmente los moví a una carpeta montada (porque para mí el último comando falló) e instalé el último con:

sudo apt-get autoremove -f

Esto resolvió mi problema.

Tuve el mismo problema, lo solucioné eliminando las sesiones de directorio de php

rm -rf /var/lib/php/sessions/

Puede estar debajo /var/lib/php5si está utilizando una versión anterior de php.

Recreala con el siguiente permiso

mkdir /var/lib/php/sessions/ && chmod 1733 /var/lib/php/sessions/

Permiso por defecto para el directorio en Debian mostró drwx-wx-wt(1733)

Experimentamos esto en una cuenta de HostGator (que establece límites de inodo en todo su alojamiento) después de un ataque de spam. Dejó un gran número de registros de cola en /root/.cpanel/comet. Si esto sucede y encuentra que no tiene inodos libres, puede ejecutar esta utilidad cpanel a través de shell:

/usr/local/cpanel/bin/purge_dead_comet_files

Puede usar RSYNC para ELIMINAR la gran cantidad de archivos

rsync -a --delete blanktest/ test/

Cree una carpeta en blanco con 0 archivos y el comando sincronizará sus carpetas de prueba con una gran cantidad de archivos (he eliminado casi 5 millones de archivos con este método).

Gracias a http://www.slashroot.in/which-is-the-fastest-method-to-delete-files-in-linux

eaccelerator podría estar causando el problema ya que compila PHP en bloques ... He tenido este problema con un servidor Amazon AWS en un sitio con una gran carga. Libere Inodes eliminando la memoria caché del acelerador en / var / cache / eaccelerator si continúa teniendo problemas.

rm -rf /var/cache/eaccelerator/*

(o cualquiera que sea su directorio de caché)

Enfrentamos un problema similar recientemente, en caso de que un proceso se refiera a un archivo eliminado, el Inode no se lanzará, por lo que debe verificar lsof /, y matar / reiniciar el proceso liberará los inodos.

Corrígeme si me equivoco aquí.

Como se dijo anteriormente, el sistema de archivos puede quedarse sin inodos, si hay muchos archivos pequeños. He proporcionado algunos medios para encontrar directorios que contienen la mayoría de los archivos aquí .

Respuesta tardía: en mi caso, fueron mis archivos de sesión bajo

/var/lib/php/sessions

que usaban Inodes.
Incluso no pude abrir mi crontab o hacer un nuevo directorio y mucho menos activar la operación de eliminación. Como uso PHP, tenemos esta guía donde copié el código del ejemplo 1 y configuré un cronjob para ejecutar esa parte del código.

<?php
// Note: This script should be executed by the same user of web server 
process.

// Need active session to initialize session data storage access.
session_start();

// Executes GC immediately
session_gc();

// Clean up session ID created by session_gc()
session_destroy();
?>

Si se pregunta cómo logré abrir mi crontab, bueno, eliminé algunas sesiones manualmente a través de la CLI.

¡Espero que esto ayude!

podías ver esta información

for i in /var/run/*;do echo -n "$i "; find $i| wc -l;done | column -t

Muchas respuestas a esta hasta ahora y todas las anteriores parecen concretas. Creo que estará seguro al usarlo a statmedida que avanza, pero dependiendo del sistema operativo, es posible que se produzcan algunos errores de inodo. Por lo tanto, implementar su propia statfuncionalidad de llamada 64bitpara evitar cualquier problema de desbordamiento parece bastante compatible.

Si usa docker, elimine todas las imágenes. Usaron mucho espacio ...

Pare todos los contenedores

docker stop $(docker ps -a -q)

Eliminar todos los contenedores

docker rm $(docker ps -a -q)

Eliminar todas las imágenes

docker rmi $(docker images -q)

Trabaja para mi