Nei sistemi Linux o Unix, la saturazione dello spazio disco è una delle cause più comuni di downtime e degrado delle prestazioni. Per gestire correttamente le risorse, non basta sapere quanto spazio è rimasto; è fondamentale capire come viene utilizzato. E per capirlo ci sono due comandi che possono aiutarci, df (Disk Free) e du (Disk Usage).
Il comando df interroga il kernel per ottenere informazioni sui file system montati. È lo strumento ideale per una diagnosi immediata dello stato di salute delle partizioni.
$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 xfs 50G 50G 0 100% /Questo comando mostra
- nome del dispositivo (es. /dev/sda1, /dev/sda2)
- tipo di filesystem (ext4, xfs, tmpfs, ecc.)
- dimensione totale del filesystem
- spazio utilizzato
- spazio disponibile
- percentuale di utilizzo
- punto di mount (es. /, /home)
Nel comando abbiamo utilizzato due opzioni
- -T (print-type): fondamentale per distinguere tra partizioni fisiche (ext4, xfs) e virtuali (tmpfs)
- -h (human-readable): converte i blocchi in MB, GB o TB.
Dopo aver individuato la partizione piena possiamo usare il comando du che permette di scansionare le directory per identificare quelle con un consumo eccessivo. Per evitare un output chilometrico e focalizzarsi sui dati rilevanti, è possibile utilizzare il flag –max-depth
$ sudo du -h --max-depth=1 /var/log | sort -h
0 /var/log/chrony
0 /var/log/private
0 /var/log/samba
0 /var/log/sssd
20K /var/log/zabbix
36K /var/log/php-fpm
4.9M /var/log/anaconda
40M /var/log/audit
46G /var/log/httpd
46G /var/logQuesto comando visualizza solo le cartelle di primo livello, ordinandole per dimensione. Sappiamo quindi che la causa dello spazio occupato al 100% è un file di log del web server Apache presente in /var/log/httpd che possiamo cancellare.
df segnala il disco pieno ma du non trova file grandi
A volte potrebbe capitare che lo spazio occupato non dipende da file “visibili”. Ci sono due cause principali per cui questo può accadere
- un file è stato cancellato ma è ancora aperto da un processo
- gli inode sono esauriti
Nel primo caso possiamo utilizzare il comando
$ sudo lsof +L1
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
[...]
httpd 77128 apache 7w REG 253,0 0 0 270044801 /var/log/httpd/access_log (deleted)
httpd 77129 apache 7w REG 253,0 0 0 270044801 /var/log/httpd/access_log (deleted)
httpd 77130 apache 7w REG 253,0 0 0 270044801 /var/log/httpd/access_log (deleted)
httpd 77131 apache 7w REG 253,0 0 0 270044801 /var/log/httpd/access_log (deleted)
[...]che elenca i file con un numero di link inferiore a 1 ma ancora aperti in memoria. La chiusura del processo associato libererà istantaneamente lo spazio su disco.
$ sudo systemctl restart httpdNel secondo caso invece, possiamo verificare lo stato degli inode con il comando
$ df -Tih
Filesystem Type Inodes IUsed IFree IUse% Mounted on
/dev/sda1 xfs 5242880 5242880 0 100% /e se la colonna IUse% è al 100%, significa che ci sono troppi file nel volume. Quello che dobbiamo cercare quindi non è una directory con file di grandi dimensioni ma directory con un numero elevato di file. Con il comando
$ sudo find / -xdev -printf '%h\n' | sort | uniq -c | sort -n | tail
12543 /usr/lib
18276 /var/cache/apt/archives
35670 /var/log
98421 /home/gitlab-runner/builds
245311 /var/lib/docker/containers
418902 /var/lib/docker/image/overlay2/layerdb
782144 /var/lib/docker/overlay2
1324578 /tmp
2876543 /var/apps/output
5242880 /possiamo vedere le cartelle con più file. Nell’esempio abbiamo un numero elevato di file nella directory di output di un’applicazione “apps” (n° 2876543 file in /var/apps/output) e file temporanei (n° 1324578 file in /tmp). Ripulendo queste cartelle dai file non necessari potremo ripristinare il corretto funzionamento del sistema.
