Errore Linux (Ubuntu) e PHP: No space left on device (ma lo spazio c'è). inode esauriti, Come risolvere?

Oggi ho affrontato un problema abbastanza peculiare su di un server Linux (Ubuntu, nello specifico). Il sito web che doveva essere erogato dal sistema non rispondeva più correttamente e, nei log di Apache HTTP Server, si leggeva soltanto il messaggio No space left on device. Ho quindi immediatamente pensato che lo spazio su disco fosse esaurito ma, con mia sorpresa, non era così. Ho infatti scoperto che la causa era da attribuirsi all'esaurimento degli inode.

Errore: No space left on device

Il messaggio completo mostrato nei log era il seguente:

PHP message: PHP Fatal error: Uncaught Exception: Warning: SessionHandler::write(): open(/var/www/.../var/session/sess_s5...7, O_RDWR) failed: No space left on device

Diventare root

Molti comandi segnalati di seguito richiedono i privilegi di root. Per semplicità, acquisiamoli immediatamente impartendo sudo -s.

Verificare lo spazio disponibile

Come prima, ovvia, verifica ho controllato quanto spazio fosse disponibile sul disco impartendo df -H.

Il comando ha però confermato che era utilizzato solo il 65% di spazio ed erano ancora disponibili ben 143 GB di spazio

Verificare il numero di inode disponibili

In ambiente Linux, ogni cartella e file archiviati su memoria persistente (hard disk o SSD) viene identificato da un numero, detto index node e abbreviato in inode. Il numero massimo di file salvabili corrisponde quindi al massimo numero di inode previsto per quella partizione.

Per vedere lo stato degli inode utilizzati e disponibili impartire df -i.

Come si vede nell'immagine seguente, il server sul quale stavo operando era in grado di gestire, per la partizione principale sda1, un massimo di 26.214.400 inode (seconda colonna della tabella). L'utilizzo era invece pari al 100%: tutti gli inode disponibili erano dunque già stati utilizzati

Come aumentare il numero di inode?

La prima idea che mi è venuta in mente è stata quella di cercare il modo di aumentare il numero di inode. Pur glissando sul fatto che si tratti di una pessima idea dal punto di vista dell'architettura (in queste situazioni è necessario cercare la causa, non risolvere il sintomo), ciò non è immediatamente possibile.

Il numero di inode viene infatti fissato al momento in cui la partizione viene creata. Per il filesystem ext4, l'ammontare viene calcolato con un rapporto di 1 inode ogni 16 kB di spazio su disco. Per aumentarli, è necessario formattare e modificare contestualmente questo rapporto: una manovra non possibile su un server di produzione.

Chi sta utilizzando tutti gli inode?

Per quanto detto in precedenza, un utilizzo così smodato di inode significa che sulla partizione sono presenti altrettanti file, la maggior parte dei quali di piccole dimensioni (altrimenti avrebbero saturato lo spazio su disco). Per risolvere il problema è dunque necessario trovare le cartelle che contengono più file ed eliminarle o spostarle su di un altra partizione. Allo scopo, lanciamo questo comando:

find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n

L'elaborazione richiederà probabilmente almeno qualche minuto.

Al termine, otterremo una lista composta dal numero di file presenti in ogni cartella. Le cartelle più popolose sono in fondo alla lista

Nel mio caso ho scoperto l'esistenza di una cartella di nome session_bkp all'interno del sito che doveva essere erogato da tale server (il nome lascia immaginare che si tratti di un backup della cartella nella quale PHP conserva le proprie sessioni). Detta cartella comprendeva 2.378.272 file: si tratta di un numero abnorme, ma non tanto da causare l'esaurimento degli inode.

Il problema era causato dal fatto che detta cartella stava venendo copiata svariate volte, probabilmente da una procedura automatica che realizzava quotidianamente una copia dell'intero sito. Questa moltiplicazione era risultata sufficiente a toccare il tetto di inode gestibili, causando il problema.

Per risolvere abbiamo semplicemente eliminato la cartella "gigante" dal sito di produzione e da tutti i backup precedenti. A quel punto, il sito è immediatamente ripartito senza manifestare ulteriori problemi.