Come utilizzare l’inode gratuito?

Ho un disco rigido in cui l’uso di inode è al 100% (usando il comando df -i ). Tuttavia, dopo aver eliminato i file in modo sostanziale, l’utilizzo rimane al 100%.

Qual è il modo corretto di farlo allora?

Come è ansible che un’unità disco con meno spazio di utilizzo del disco possa avere un utilizzo di Inode più elevato rispetto all’unità disco con un utilizzo maggiore dello spazio su disco?

E ‘ansible se io comprimo molti file che ridurrebbe il numero di inode usato?

È abbastanza facile per un disco avere un numero elevato di inode utilizzati anche se il disco non è pieno.

Un inode viene assegnato a un file, quindi, se disponi di migliaia di miliardi di file, tutti 1 byte ciascuno, finirai per esaurire gli inode molto prima che finisca il disco.

È anche ansible 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 uno non libererà l’inode.

Inoltre, è ansible eliminare una voce di 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 è ansible, quindi riavviare la scatola per assicurarsi che non vengano lasciati processi in attesa di aprire i file.

Se lo fai e hai ancora un problema, 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 lo scipt. Puoi verificarlo con df -ih .

Quindi questo comando bash può aiutarti a:

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

E sì, ci vorrà del tempo, ma puoi trovare la directory con il maggior numero di file.

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

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

Sono su una Ubuntu 12.04LTS e non posso 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 quindi ero bloccato.

Ho finito per cancellare alcuni vecchi kernel Linux a mano per liberare circa 10.000 inode

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

Questo è stato sufficiente per permettermi di 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 vanno molto meglio ora

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

La mia soluzione:

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

 df -ih 

Prova a trovare le cartelle radice con conteggio di grandi inode:

 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 linux, provare a rimuovere il più vecchio con:

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

Personalmente li ho spostati in una cartella montata (perché per me l’ultimo comando è fallito) e ho installato l’ultima 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 in /var/lib/php5 se stai usando una versione php precedente.

Ricreala con la seguente authorization

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

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

eaccelerator potrebbe causare il problema poiché compila PHP in blocchi … Ho avuto questo problema con un server Amazon AWS su un sito con un carico pesante. 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 directory della cache)

Lo abbiamo sperimentato su un account HostGator (che pone limiti di inode su tutto il loro hosting) in seguito a un attacco di spam. Ha lasciato un vasto numero di record di coda in /root/.cpanel/comet. Se ciò accade e scopri di non avere inode liberi, puoi eseguire questo programma di utilità cpanel tramite shell:

 /usr/local/cpanel/bin/purge_dead_comet_files 

Abbiamo affrontato problemi simili recentemente, nel caso in cui un processo si riferisca a un file cancellato, l’Inode non deve essere rilasciato, quindi è necessario controllare lsof /, e kill / restart il processo rilascerà gli inode.

Correggimi se sbaglio qui.

È ansible utilizzare RSYNC per ELIMINARE il numero elevato di file

 rsync -a --delete blanktest/ test/ 

Crea una cartella vuota con 0 file al suo interno e comando sincronizzerà le tue cartelle di test con un numero elevato 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

Come detto prima, il filesystem può 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 .

Molte risposte a questo finora e tutte quelle sopra sembrano concrete. Penso che sarai al sicuro usando stat mentre vai avanti, ma a seconda del sistema operativo, potresti avere degli errori inode che ti si insinuano. Quindi, implementare la propria funzionalità di chiamata stat utilizzando 64bit per evitare problemi di overflow sembra abbastanza compatibile.

La directory di posta può essere piena di file:

/ Home / nomeutente / Maildir / new