Como liberar o uso de inode?

Eu tenho uma unidade de disco em que o uso do inode é 100% (usando o df -icomando). No entanto, após a exclusão substancial de arquivos, o uso permanece 100%.

Qual é a maneira correta de fazer isso?

Como é possível que uma unidade de disco com menos uso de espaço em disco possa ter maior uso de Inode do que uma unidade de disco com maior uso de espaço em disco?

É possível se eu compactar muitos arquivos que reduziriam a contagem de inodes usados?

É muito fácil para um disco usar um grande número de inodes, mesmo que o disco não esteja muito cheio.

Um inode é alocado para um arquivo, portanto, se você tiver zilhões de arquivos, todos com 1 byte cada, ficará sem inodes muito antes de ficar sem disco.

Também é possível que a exclusão de arquivos não reduza a contagem de inodes se os arquivos tiverem vários links físicos. Como eu disse, os inodes pertencem ao arquivo, não à entrada do diretório. Se um arquivo tiver duas entradas de diretório vinculadas, a exclusão de uma não liberará o inode.

Além disso, você pode excluir uma entrada de diretório, mas, se um processo em execução ainda tiver o arquivo aberto, o inode não será liberado.

Meu conselho inicial seria excluir todos os arquivos que você puder e, em seguida, reinicie a caixa para garantir que nenhum processo seja deixado mantendo os arquivos abertos.

Se você fizer isso e ainda tiver um problema, informe-nos.

A propósito, se você estiver procurando os diretórios que contêm muitos arquivos, este script pode ajudar:

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

Se você é muito azarado, usou cerca de 100% de todos os inodes e não pode criar o scipt. Você pode verificar isso com df -ih.

Então este comando bash pode ajudá-lo:

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

E sim, isso levará tempo, mas você pode localizar o diretório com mais arquivos.

Minha situação era que eu estava sem inodes e já havia excluído tudo o que podia.

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

Estou em um ubuntu 12.04LTS e não foi possível remover os antigos kernels do linux, que ocupavam cerca de 400.000 inodes porque o apt foi quebrado por causa de um pacote ausente. E não consegui instalar o novo pacote porque estava sem inodes, por isso fiquei preso.

Acabei excluindo alguns kernels Linux antigos manualmente para liberar cerca de 10.000 inodes

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

Isso foi o suficiente para, então, deixar-me instalar o pacote que faltava e corrigir meu apt

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

e remova o restante dos antigos kernel do linux com o apt

$ sudo apt-get autoremove

as coisas estão muito melhores agora

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

Minha solução:

Tente descobrir se este é um problema de inodes com:

df -ih

Tente encontrar pastas raiz com grande número de inodes:

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

Tente encontrar pastas específicas:

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

Se esse for o cabeçalho do linux, tente remover o mais antigo com:

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

Pessoalmente, mudei-os para uma pasta montada (porque para mim o último comando falhou) e instalei o mais recente com:

sudo apt-get autoremove -f

Isso resolveu meu problema.

Eu tive o mesmo problema, corrigi-o removendo as sessões de diretório do php

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

Pode estar sob /var/lib/php5 se você estiver usando uma versão php mais antiga.

Recrie-o com a seguinte permissão

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

A permissão por padrão para o diretório no Debian foi mostrada drwx-wx-wt(1733)

Experimentamos isso em uma conta HostGator (que impõe limites de inode a toda a hospedagem) após um ataque de spam. Ele deixou um grande número de registros de fila em /root/.cpanel/comet. Se isso acontecer e você achar que não possui inodes gratuitos, poderá executar este utilitário cpanel através do shell:

/usr/local/cpanel/bin/purge_dead_comet_files

Você pode usar o RSYNC para excluir o grande número de arquivos

rsync -a --delete blanktest/ test/

Crie uma pasta blanktest com 0 arquivos e o comando sincronizará suas pastas de teste com um grande número de arquivos (eu excluí quase 5 milhões de arquivos usando este método).

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

O eaccelerator pode estar causando o problema, pois compila o PHP em blocos ... Eu tive esse problema com um servidor Amazon AWS em um site com carga pesada. Libere os inodes excluindo o cache do eaccelerator em / var / cache / eaccelerator se você continuar com problemas.

rm -rf /var/cache/eaccelerator/*

(ou qualquer que seja o diretório do cache)

Enfrentamos um problema semelhante recentemente. Caso um processo se refira a um arquivo excluído, o Inode não será liberado; portanto, você deve verificar lsof / e interromper / reiniciar o processo liberará os inodes.

Corrija-me se estiver errado aqui.

Como dito anteriormente, o sistema de arquivos pode ficar sem inodes, se houver muitos arquivos pequenos. Forneci alguns meios para encontrar diretórios que contêm a maioria dos arquivos aqui .

Resposta tardia: no meu caso, eram meus arquivos de sessão em

/var/lib/php/sessions

que estavam usando inodes.
Eu até consegui abrir o meu crontab ou criar um novo diretório e muito menos acionar a operação de exclusão. Como uso o PHP, temos este guia onde copiei o código do exemplo 1 e configurei um cronjob para executar essa parte do 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();
?>

Se você está se perguntando como eu consegui abrir meu crontab, então excluí algumas sessões manualmente através da CLI.

Espero que isto ajude!

você pode ver esta informação

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

Muitas respostas até agora e todas as opções acima parecem concretas. Eu acho que você estará seguro usando à statmedida que avança, mas dependendo do SO, você pode receber alguns erros de inode. Portanto, implementar sua própria statfuncionalidade de chamada 64bitpara evitar problemas de estouro parece bastante compatível.

Se você usar a janela de encaixe, remova todas as imagens. Eles usaram muito espaço ....

Pare todos os contêineres

docker stop $(docker ps -a -q)

Excluir todos os contêineres

docker rm $(docker ps -a -q)

Excluir todas as imagens

docker rmi $(docker images -q)

Trabalha para mim