Negli ultimi mesi ho avuto a che fare con un paio di problemi riguardo allo spazio su disco sulle macchine che gestisco, sono casi abbastanza rari ma piuttosto curiosi che vorrei condividere.
Solitamente nelle installazioni server la gestione dei dischi, per chi non fosse ferrato sull’argomento, è un po’ diversa dall’installazione di un sistema su un portatile in quanto conviene sempre partizionare il disco a seconda degli utilizzi. Si tende infatti sempre a evitare di mettere tutti i dati in una sola partizione per evitare che il riempimento porti a un’instabilità del servizio installato o del sistema intero. Un altro vantaggio dell’avere partizioni multiple è la possibilità di montare directory direttamente su dischi separati anche per poterli gestire successivamente: nel mondo di AWS è molto comodo vista la possibilità di poterli ingrandire con un click.
Uno degli esempi più comuni è la separazione della partizione /home, ma possono esserci altri esempi come nel mio caso le directory /opt /db /logs e /tmp sono tutte su partizioni e dischi separati.
Capita però che per errori di configurazione, o semplicemente per sfortuna, le cose vadano a rotoli nelle maniere più strane.
Il primo caso che voglio descrivere è partito da uno dei nostri controlli che ci sveglia con:
cannot touch ‘/opt/myfile’: No space left on device
e già qui scopro un errore di configurazione: un symbolic link avrebbe dovuto puntare a una directory su una partizione separata ma alla fine il percorso era sulla partizione di root: fin qui nulla di tragico, errore sì, ma non era previsto un utilizzo di spazio eccessivo.
Però df -h mi dice che la partizione di root è usata al 70% circa, perchè non ho quel messaggio di errore?
Così mi venne in mente una cosa: inodes, quei piccoli bastardi!!!
In Linux, un inode (indice nodo) è una struttura di dati che rappresenta un singolo file o directory nel sistema di file e a ogni file o directory è associato a un inode univoco – Grazie chatgpt
Ho pensato che un qualche processo generasse miriadi di file piccoli o vuoti che avrebbero saturato la capacità degli inodes; avendo partizionato il disco la partizione di root non è particolarmente grande e il numero di inodes disponibili dipende dalla dimensione del file system.
Quindi ho pescato tra miei appunti un primo comando che va a contare i file
find / -xdev -type f | cut -d “/” -f 2 | sort | uniq -c | sort -n
Ma non ha dato un risultato sperato, nessun valore era fuori scala, se non fosse che in un altro post ho trovato un comando diverso
for i in /*; do echo $i; find $i | wc -l; done
e qui mi ritrovo 5 milioni di directory annidate e vuote
/db
5130921
Quindi, messo in piedi un task periodico di pulizia, il disco è tornato a respirare … e abbiamo anche sistemato la directory sulla partizione giusta.
Se il primo caso partiva con un “non riesco a scrivere perché il disco è pieno anche se non sembra” il secondo è “ho il disco pieno, ma non so dove si è riempito, quindi non so come ripulirlo”
Anche in questo caso la vittima è la partizione di root che mi sono trovato piena: unico indizio … si è riempita poco tempo dopo un reboot.
Dopo una serie di elucubrazioni arriviamo al dunque: a seguito del riavvio, il sistema non ha montato, solo in quel caso e per ragioni che non ho capito, il disco dove è montata la directory /logs.
L’applicativo e gli altri servizi hanno quindi iniziato a loggare sì nella directory logs ma sulla partizione di sistema, riempiendola.
Nel cercare ci capirci qualcosa sono stati fatti diversi riavvii, ma da dopo il fattaccio, le partizioni venivano montate correttamente nascondendo sotto il tappeto la directory /logs sulla partizione di sistema rendendo il contenuto invisibile.
L’unico modo per uscirne è stato quello di stoppare tutti i servizi e verificare con lsof che nulla scrivesse in quella directory.
Da lì è stato necessario smontare la partizione corretta per rendere visibile il contenuto della stessa directory sulla partizione di sistema, ripulire tutto, rimontare le partizioni e riavviare tutti i sistemi … o riavviare la macchina, tanto sarebbe ripartito tutto in automatico.
Ovvio che sono due casi piuttosto specifici, ma se in futuro vi capitasse di non capire chi vi ha rubato lo spazio su disco, controllare inodes e montaggio dei filesystem potrebbe risparmiarvi un po’ di mal di testa o meglio ancora downtime dei servizi.
Source: Dov’è finito lo spazio su disco?