Dopo un deploy, il problema non è solo “quanto spazio resta”. Il punto è capire se LVM, btrfs, quota e scheduler I/O stanno lavorando come previsto.
Qui trovi una mini checklist da eseguire subito su un server già online. L’obiettivo è semplice: scoprire errori di montaggio, snapshot troppo pieni, quote fuori controllo e colli di bottiglia I/O prima che arrivino i sintomi.
Scenario tipico: una VM parte bene, ma dopo poche ore compaiono rallentamenti, log troncati o il classico No space left on device. In molti casi il disco non è davvero pieno. È un mix di snapshot, metadata esauriti, quota rigide o filesystem montato in modo diverso da come pensavi.
Prerequisiti
Servono accesso root o sudo, e almeno questi strumenti:
- LVM:
lvs,vgs,pvs,lvdisplay - btrfs:
btrfs filesystem usage,btrfs subvolume list,btrfs qgroup show - Quota:
quota,repquota,findmnt - I/O:
cat /sys/block/*/queue/scheduler,iostat,lsblk
Note: i nomi dei pacchetti cambiano tra distro. Su Debian e Ubuntu trovi spesso sysstat per iostat. Su RHEL, Rocky e Alma il comando arriva dallo stesso pacchetto, ma la disponibilità dipende dall’installazione minima.
Step 1: conferma il layout reale, non quello atteso
Perché farlo subito? Perché molti problemi nascono da un mount point diverso, da un LV esteso ma non rimontato, o da un btrfs su sottovolume sbagliato.
Controlla prima chi sta servendo cosa.
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /
lsblk -f
lvs -a -o lv_name,vg_name,lv_size,segtype,data_percent,metadata_percent
btrfs filesystem show
# Output:
/ deve puntare al filesystem previsto. lvs deve mostrare metadata_percent coerente. btrfs filesystem show deve elencare il device atteso, non un vecchio disco rimasto nel server.
Perché funziona: prima di toccare quota o snapshot, devi sapere quale volume è realmente montato e quale layer sta saturando.
Nota cross-distro: su sistemi con util-linux vecchio, findmnt può mostrare meno colonne. Il controllo resta valido anche con output ridotto.
Step 2: verifica spazio libero e, soprattutto, metadata
Su LVM il filesystem può apparire libero, ma il thin pool può essere vicino al limite. Su btrfs il problema può essere nei metadata, non nei dati.
Questo è il controllo che salva più incidenti di quanto sembri.
df -hT /
df -ih /
lvs -a -o lv_name,vg_name,lv_size,data_percent,metadata_percent,lv_attr
btrfs filesystem usage -T /
# Output:
Vuoi vedere spazio residuo reale e percentuali sane. Se metadata_percent è alto, il filesystem può bloccarsi anche con dati ancora disponibili.
Perché funziona: i metadata finiscono prima dei dati in vari scenari btrfs e thin LVM, e il sintomo esterno è spesso un errore generico di scrittura.
Warning: non fidarti solo di df -h. Un filesystem può sembrare al 20% e rifiutare comunque nuove scritture.
Step 3: controlla snapshot e retention prima che divorino spazio
Gli snapshot sono utili solo se hanno una politica chiara. Dopo il deploy, verifica quanti ne hai, quanto occupano e se sono ancora necessari.
lvs -a -o lv_name,origin,lv_size,data_percent,lv_time,lv_attr
btrfs subvolume list /
btrfs qgroup show -reF /
# Output:
Gli snapshot LVM devono essere pochi e monitorati. Su btrfs, i qgroup devono riflettere una crescita coerente, non una cascata di subvolumi non più usati.
Perché funziona: uno snapshot vecchio trattiene blocchi modificati e impedisce al filesystem di recuperare spazio.
Note: su alcune distro i qgroup non sono attivi di default. Se btrfs qgroup show restituisce poco o nulla, controlla se la quota di btrfs è stata inizializzata.
Step 4: valida quota utente, gruppo e progetto
Le quote sono spesso il primo punto in cui un deploy “sano” si rompe. Bastano un backup temporaneo, un upload massivo o una cache applicativa troppo aggressiva.
Controlla quote attive e valori reali. Poi verifica se l’app gira con l’utente giusto.
quota -u $(whoami)
quota -g $(id -gn)
repquota -a
id
# Output:
Se la quota è attiva, devi vedere limiti e utilizzo. Se non è attiva, il comando lo segnala chiaramente o restituisce dati incompleti.
Perché funziona: molte scritture fallite non dipendono dallo spazio globale, ma dal limite dell’utente o del gruppo che esegue il servizio.
Nota cross-distro: su sistemi con XFS, la quota può essere gestita in modo diverso rispetto a ext4 o btrfs. Il principio resta identico: controlla chi scrive e con quali limiti.
Step 5: controlla l’I/O scheduler e la coda del disco
Un filesystem pieno non è l’unica causa di lentezza. Un scheduler I/O sbagliato può amplificare il problema e far sembrare il nodo saturo anche quando non lo è.
Verifica lo scheduler effettivo per i device usati dal volume.
for d in /sys/block/sd*/queue/scheduler /sys/block/nvme*/queue/scheduler; do
[ -e "$d" ] && echo "$d: $(cat "$d")"
done
iostat -xz 1 3
# Output:
Lo scheduler corrente appare tra parentesi quadre. iostat deve mostrare valori coerenti con il carico e non una latenza costantemente alta.
Perché funziona: se il disco risponde lentamente, le code si allungano, i processi attendono e il sistema sembra “pieno” anche quando il limite è altrove.
Note: con NVMe spesso lo scheduler è none. Su SATA e dischi virtuali, la scelta può cambiare il comportamento sotto carico.
Step 6: cerca i sintomi nel journal prima di aprire il ticket
Se il filesystem è davvero in difficoltà, il journal lo dice quasi sempre prima dell’utente finale.
Filtra i messaggi più utili: errori di mount, write failure, quota exceeded, read-only remount.
journalctl -p warning..alert -b | grep -Ei 'no space|quota|read-only|btrfs|ext4|xfs|I/O error|remount'
dmesg -T | grep -Ei 'no space|write error|quota|btrfs|buffer i/o|read-only'
# Output:
Ti aspetti righe con timestamp vicini all’ora del problema. Se trovi Remounting filesystem read-only, il nodo richiede attenzione immediata.
Perché funziona: il kernel e il journal registrano la causa tecnica, non solo il sintomo applicativo.
Verifica finale
Quando hai finito i controlli, fai una passata finale con una checklist corta. Deve dirti se il server è pronto o se stai solo rimandando il guasto.
- Il mount point corretto è attivo con
findmnt. dfelvsmostrano margine reale, non solo apparente.- Gli snapshot sono pochi e hanno una retention esplicita.
- Le quote dell’utente di servizio sono compatibili con il carico previsto.
- Lo scheduler I/O è quello atteso per il tipo di disco.
- Il journal non mostra errori di scrittura o remount read-only.
Se vuoi automatizzare il controllo, salva l’output in un file di audit dopo ogni deploy.
mkdir -p /var/log/storage-audit
{
date
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /
df -hT /
lvs -a -o lv_name,vg_name,lv_size,data_percent,metadata_percent,lv_attr
btrfs filesystem usage -T /
} > /var/log/storage-audit/$(date +%F-%H%M).log
# Output:
Un file con timestamp, leggibile anche a distanza di settimane, utile per confrontare il prima e il dopo di un deploy.
Perché funziona: senza una traccia storica, i problemi di spazio sembrano improvvisi anche quando crescono da giorni.
Troubleshooting
Errore: No space left on device
Causa: lo spazio dati può esserci ancora, ma il filesystem ha esaurito metadata, inode o quota dell’utente.
Fix: verifica subito il collo di bottiglia reale.
df -ih /
lvs -a -o lv_name,metadata_percent,data_percent,lv_attr
quota -u $(whoami)
Output atteso: individui se il limite è inode, metadata o quota. Poi liberi snapshot vecchi o aumenti i limiti.
Errore: cannot allocate memory for new block group
Causa: su btrfs i metadata o la frammentazione interna possono impedire nuove allocazioni, anche con spazio apparente.
Fix: controlla l’uso reale e riequilibra solo se necessario.
btrfs filesystem usage -T /
btrfs balance start -dusage=75 -musage=75 /
Output atteso: l’uso dei block group si normalizza. Se il filesystem è molto pieno, il balance può richiedere tempo.
Errore: Buffer I/O error on dev sda
Causa: il layer disco o la VM storage backend sta rifiutando operazioni, spesso per latenza, problemi del device o thin pool saturo.
Fix: verifica il device e lo stato del pool, poi riduci il carico di scrittura.
iostat -xz 1 5
lvs -a -o lv_name,lv_attr,data_percent,metadata_percent
journalctl -k -b | grep -Ei 'Buffer I/O error|thin pool|I/O error'
Output atteso: capisci se il problema è fisico, virtuale o legato a saturazione del pool.
Conclusione
Una verifica storage post-deploy fatta bene evita incidenti rumorosi e ticket inutili. LVM, btrfs, quota e scheduler vanno letti insieme, non uno alla volta.
Il prossimo passo concreto è trasformare questi comandi in uno script di audit post-release, con soglie minime e un alert quando metadata, quota o snapshot superano il limite deciso.
Note: se il server ospita servizi critici, esegui la checklist dopo ogni cambio di volume, non solo dopo il deploy iniziale.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.