Come utilizzare gratuitamente Inode?

Ho un disco rigido in cui l'utilizzo dell'inode è del 100% (usando il df -icomando). Tuttavia, dopo aver eliminato sostanzialmente i file, l'utilizzo rimane del 100%.

Qual è il modo corretto di farlo allora?

Come è possibile che un'unità disco con un minore utilizzo dello spazio su disco possa avere un maggiore utilizzo di Inode rispetto all'unità disco con un maggiore utilizzo dello spazio su disco?

È possibile se comprimere molti file riducendo il conteggio degli inode utilizzati?

È abbastanza facile per un disco utilizzare un gran numero di inode anche se il disco non è molto pieno.

Un inode viene allocato in un file, quindi, se si dispone di milioni di file, tutti da 1 byte ciascuno, si esauriranno gli inode molto prima di rimanere senza disco.

È anche possibile che l'eliminazione dei file non riduca il conteggio degli inode se i file hanno più collegamenti fisici. Come ho detto, gli inode appartengono al file, non alla voce della directory. Se un file ha due voci di directory collegate ad esso, l'eliminazione di una non libererà l'inode.

Inoltre, è possibile eliminare una voce della directory ma, se un processo in esecuzione ha ancora il file aperto, l'inode non verrà liberato.

Il mio consiglio iniziale sarebbe quello di eliminare tutti i file che è possibile, quindi riavviare la casella per assicurarsi che nessun processo rimanga aperto.

Se lo fai e hai ancora problemi, faccelo sapere.

A proposito, se stai cercando le directory che contengono molti file, questo script può aiutare:

#!/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 sei molto sfortunato hai usato circa il 100% di tutti gli inode e non puoi creare la scipt. Puoi verificarlo con df -ih.

Quindi questo comando bash può aiutarti:

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

E sì, ci vorrà del tempo, ma è possibile individuare la directory con il maggior numero di file.

La mia situazione era che ero fuori dagli inode e avevo già cancellato tutto ciò che potevo.

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

Sono su Ubuntu 12.04LTS e non sono riuscito a rimuovere i vecchi kernel Linux che occupavano circa 400.000 inode perché apt era rotto a causa di un pacchetto mancante. E non ho potuto installare il nuovo pacchetto perché ero fuori dagli inode e quindi ero bloccato.

Ho finito per eliminare manualmente alcuni vecchi kernel Linux per liberare circa 10.000 inode

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

Questo è stato sufficiente per farmi installare il pacchetto mancante e correggere il mio apt

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

e quindi rimuovere il resto dei vecchi kernel Linux con apt

$ sudo apt-get autoremove

le cose adesso vanno molto meglio

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

La mia soluzione:

Prova a scoprire se questo è un problema di inode con:

df -ih

Prova a trovare le cartelle principali con un conteggio di inode di grandi dimensioni:

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

Prova a trovare cartelle specifiche:

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

Se si tratta di intestazioni di Linux, prova a rimuovere la versione più vecchia con:

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

Personalmente li ho spostati in una cartella montata (perché l'ultimo comando non è riuscito) e ho installato l'ultimo con:

sudo apt-get autoremove -f

Questo ha risolto il mio problema.

Ho avuto lo stesso problema, risolto rimuovendo le sessioni di directory di php

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

Potrebbe essere sotto /var/lib/php5se stai usando una versione php precedente.

Ricrealo con la seguente autorizzazione

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

Autorizzazione di default per la directory su Debian mostrata drwx-wx-wt(1733)

Lo abbiamo riscontrato su un account HostGator (che pone limiti di inode su tutto il loro hosting) a seguito di un attacco di spam. Ha lasciato un gran numero di record di coda in /root/.cpanel/comet. Se ciò accade e scopri che non hai inode gratuiti, puoi eseguire questa utility cpanel tramite shell:

/usr/local/cpanel/bin/purge_dead_comet_files

È possibile utilizzare RSYNC per ELIMINARE il numero elevato di file

rsync -a --delete blanktest/ test/

Crea una cartella più vuota con 0 file al suo interno e il comando sincronizzerà le tue cartelle di prova con un gran numero di file (ho eliminato quasi 5 milioni di file usando questo metodo).

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

eaccelerator potrebbe causare il problema poiché compila PHP in blocchi ... Ho avuto questo problema con un server Amazon AWS in un sito con carichi pesanti. Libera gli Inode eliminando la cache di eaccelerator in / var / cache / eaccelerator se continui ad avere problemi.

rm -rf /var/cache/eaccelerator/*

(o qualunque sia la tua directory cache)

Di recente abbiamo riscontrato un problema simile, nel caso in cui un processo si riferisca a un file eliminato, l'Inode non deve essere rilasciato, quindi è necessario controllare lsof / e uccidere / riavviare il processo rilascerà gli inode.

Correggimi se sbaglio qui.

Come detto prima, il filesystem potrebbe esaurire gli inode, se ci sono molti piccoli file. Ho fornito alcuni mezzi per trovare le directory che contengono la maggior parte dei file qui .

Risposta in ritardo: nel mio caso, erano i miei file di sessione in

/var/lib/php/sessions

che stavano usando gli Inodi.
Non sono stato nemmeno in grado di aprire il mio crontab o di creare una nuova directory e tanto meno di innescare l'operazione di cancellazione. Da quando uso PHP, abbiamo questa guida in cui ho copiato il codice dall'esempio 1 e impostato un cronjob per eseguire quella parte del codice.

<?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 ti stai chiedendo come sono riuscito ad aprire il mio crontab, allora ho eliminato alcune sessioni manualmente tramite la CLI.

Spero che questo ti aiuti!

potresti vedere queste informazioni

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

Molte risposte a questa finora e tutto quanto sopra sembra concreto. Penso che sarai al sicuro usando statmentre procedi, ma a seconda del sistema operativo, potresti avere alcuni errori di inode che si insinuano su di te. Quindi l'implementazione della propria statfunzionalità di chiamata 64bitper evitare problemi di overflow sembra abbastanza compatibile.

Se si utilizza la finestra mobile, rimuovere tutte le immagini. Hanno usato molti spazi ...

Ferma tutti i contenitori

docker stop $(docker ps -a -q)

Elimina tutti i contenitori

docker rm $(docker ps -a -q)

Elimina tutte le immagini

docker rmi $(docker images -q)

Funziona con me