linux - see - inodes full

¿Cómo liberar el uso de inodo? (11)

Tengo una unidad de disco donde el uso del inodo es del 100% (usando el comando df -i ). 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 conteo de inodos usados?

Como se dijo antes, 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 here .

Es bastante fácil que un disco tenga una gran cantidad de inodos, incluso si el disco no está muy lleno.

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

También es posible que la eliminación de archivos no reduzca el recuento de inodos si los archivos tienen varios enlaces físicos. Como dije, los inodos pertenecen al archivo, no a la entrada del directorio. Si un archivo tiene dos entradas de directorio vinculadas a él, eliminar una no liberará el inodo.

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

Mi consejo inicial sería eliminar todos los archivos que pueda y luego reiniciar el cuadro para garantizar que no queden procesos que mantengan los archivos abiertos.

Si lo hace y todavía tiene un problema, háganoslo saber.

Por cierto, si está buscando los directorios que contienen muchos archivos, esta secuencia de comandos puede ayudar:

#!/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_$$

Experimentamos esto en una cuenta de HostGator (que coloca 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 descubre que no tiene inodos libres, puede ejecutar esta utilidad cpanel a través de la shell:

/usr/local/cpanel/bin/purge_dead_comet_files

Mi situación era que ya no tenía inodos y ya había borrado todo lo que podía.

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

Estoy en una ubuntu 12.04LTS y no pude eliminar los viejos núcleos de Linux que consumieron unos 400,000 inodos porque apt estaba roto debido a que faltaba un paquete. Y no pude instalar el nuevo paquete porque no tenía inodos, así que me quedé atascado.

Terminé eliminando algunos viejos núcleos de Linux a mano para liberar unos 10.000 inodos

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

Esto fue suficiente para luego dejarme instalar el paquete faltante y arreglar mi apt.

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

y luego retire 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:

Trate de encontrar si este es un problema de inodos con:

df -ih

Trate de encontrar carpetas raíz con gran número de inodos:

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

Trate de encontrar carpetas específicas:

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

Si esto es 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 el último comando para mi falló) e instalé la última con:

sudo apt-get autoremove -f

Esto solucionó mi problema.

Muchas respuestas a esta hasta ahora y todas las anteriores parecen concretas. Creo que estarás seguro al usar stat medida que avanzas, pero dependiendo del sistema operativo, puedes obtener algunos errores de inodo que te acechan. Por lo tanto, la implementación de su propia funcionalidad de llamada stat con 64bit para evitar cualquier problema de desbordamiento parece bastante compatible.

Puedes usar RSYNC para BORRAR la gran cantidad de archivos

rsync -a --delete blanktest/ test/

Cree una carpeta de prueba en blanco con 0 archivos en ella 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

Recientemente tuvimos un problema similar. En caso de que un proceso se refiera a un archivo eliminado, el Inode no se liberará, por lo que debe verificar lsof /, y al finalizar / matar el proceso se liberarán los inodes.

Corrígeme si estoy equivocado aquí.

Si tiene muy mala suerte, ha utilizado aproximadamente el 100% de todos los inodos y no puede crear el fragmento. Puedes verificar esto con df -ih .

Entonces este comando de 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.

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

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

Puede estar bajo /var/lib/php5 si está usando una versión anterior de php.

Recrearlo con el siguiente permiso.

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

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

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

rm -rf /var/cache/eaccelerator/*

(o lo que sea tu dir caché)