1,201 26/03/2026 07/04/2026 6 min

Quando lo storage Linux va storto, il sintomo raro non è solo il disco pieno. Spesso il blocco nasce tra livelli diversi: LVM che sembra avere spazio, btrfs che rifiuta nuove scritture, snapshot che non avanzano, quota che non si aggiorna.

Il caso tipico è questo: una VM o un server fisico monta /var o /home su btrfs dentro un logical volume LVM. Dopo un rollback, un resize o la cancellazione di file pesanti, il filesystem continua a rispondere con ENOSPC. Anche con spazio libero visibile da pvs o lvs.

Qui la priorità non è “fare ordine”. La priorità è capire quale livello sta mentendo, fermare il danno, e ripristinare il servizio senza peggiorare la situazione.

Prerequisiti

Serve accesso root o sudo. Serve anche una finestra di manutenzione se il filesystem è già in sola lettura o se servizi critici scrivono su /var.

  • Kernel e tool recenti: lvm2, btrfs-progs, util-linux.
  • Un secondo punto di accesso, come console IPMI, KVM o pannello provider.
  • Spazio libero su un altro volume, anche temporaneo, per copie di emergenza.
  • Note: i comandi qui sotto sono da terminale. Se usi cockpit o un pannello storage, la logica resta la stessa, ma il monitoraggio dettagliato è più limitato.

Step numerati

1. Capire dove si ferma la scrittura

Prima distingui il livello fisico da quello logico. LVM può avere extents liberi, ma btrfs può avere block group saturi o quota non riallineata.

df -hT /var
lsblk -f
pvs
vgs
lvs -a -o+devices,data_percent,metadata_percent
btrfs filesystem df /var
btrfs quota rescan -w /var

# Output: /var mostra filesystem quasi pieno oppure btrfs filesystem df evidenzia spazio apparentemente disponibile ma non allocabile.

Se df mostra 100% e btrfs filesystem df mostra ancora metadata o data liberi, il problema può essere frammentazione, quota non aggiornata o snapshot troppo numerosi.

2. Verificare se il blocco arriva da quota o snapshot

Con btrfs, quota e snapshot possono consumare spazio in modo poco intuitivo. Un rollback LVM non elimina i riferimenti interni del filesystem. Se la quota è attiva, il rescan può essere obbligatorio.

btrfs qgroup show -reF /var
btrfs subvolume list /var
btrfs subvolume get-default /var

# Output: una lista di qgroup con consumo alto, snapshot numerosi, oppure un subvolume predefinito diverso da quello atteso.

Warning: non cancellare snapshot alla cieca. Se il backup punta a un subvolume preciso, puoi rompere il ripristino o perdere il rollback previsto.

3. Liberare spazio senza toccare il filesystem sbagliato

Se il volume LVM è davvero pieno, allarga il logical volume prima di intervenire su btrfs. Se invece il volume ha spazio, non forzare un resize del filesystem senza prima capire la causa.

lvdisplay /dev/vgdata/lvvar
lvextend -r -L +20G /dev/vgdata/lvvar

# Output: il logical volume cresce e, con -r, anche il filesystem viene espanso se supportato.

Se sei in emergenza e il filesystem è ancora montato in lettura-scrittura, puoi liberare file grandi e ricostruibili. Log, cache e dump sono i primi candidati.

du -xhd1 /var | sort -h
journalctl --vacuum-time=7d
find /var/cache -type f -mtime +30 -delete

# Output: riduzione immediata dell’occupazione, con spazio recuperato in /var/log o /var/cache.

4. Sistemare i qgroup quando il rescan non termina

Se btrfs quota rescan -w resta bloccato o non aggiorna i numeri, la causa più comune è una tabella qgroup incoerente dopo snapshot, delete massicci o rollback.

btrfs quota disable /var
btrfs quota enable /var
btrfs quota rescan -w /var

# Output: quota disabilitata e riabilitata, poi rescan completato senza errori.

Questo passaggio è delicato ma spesso risolutivo. Disattivare e riattivare la quota forza btrfs a ricalcolare i riferimenti. Se il filesystem è molto grande, l’operazione può richiedere tempo.

5. Preparare un rollback vero, non solo un riavvio

Se il problema nasce dopo un rollback LVM, bisogna distinguere tra rollback del volume e stato interno del filesystem. Un revert del blocco non sempre ripristina l’indice dei subvolume o delle quote.

mount | grep ' /var '
btrfs scrub start -Bd /var
btrfs device stats /var

# Output: mount attivo, scrub completato, nessun errore grave sui device.

Se lo scrub segnala errori, il rollback non basta. In quel caso conviene fermare i servizi, prendere una copia del volume e valutare il restore da snapshot sano o da backup esterno.

6. Ripristinare il servizio con una strategia a basso rischio

Quando il servizio deve tornare online, procedi dal meno invasivo al più invasivo. Prima smonta, poi rimonta, poi ripara i metadati logici, solo dopo valuta un restore completo.

systemctl stop rsyslog nginx postgresql 2>/dev/null
umount /var
mount /var
systemctl start rsyslog nginx postgresql 2>/dev/null

# Output: i servizi ripartono se il problema era solo lo stato di mount o un lock temporaneo.

Se il mount fallisce, non insistere con reboot ripetuti. Meglio avviare in rescue mode, montare il volume in sola lettura e copiare fuori i dati essenziali.

Verifica finale

Dopo la correzione, fai tre controlli. Il primo è lo spazio percepito dal sistema. Il secondo è la salute di LVM. Il terzo è la coerenza di btrfs.

df -hT /var
lvs -a -o+data_percent,metadata_percent
btrfs filesystem usage /var
btrfs quota rescan -w /var

# Output: spazio coerente tra df, lvs e btrfs; rescan completato senza errori.

Controlla anche i log del kernel. Cerca segni di write error, metadata exhaustion o remount read-only.

dmesg -T | egrep -i 'btrfs|ext4|xfs|error|readonly|enospc'
journalctl -p err -b

# Output: nessun nuovo errore di filesystem o I/O dopo il ripristino.

Troubleshooting

Errore: BTRFS error (device dm-0): ENOSPC: could not allocate chunk

Causa: i chunk btrfs non trovano spazio allocabile, spesso per metadata saturi o snapshot troppo numerosi.

Fix:

btrfs balance start -dusage=75 -musage=75 /var

# Output: il bilanciamento libera blocchi e riduce la pressione sui chunk pieni.

Errore: ERROR: cannot access subvolume quota groups

Causa: qgroup incoerenti dopo clone, snapshot o restore incompleto.

Fix:

btrfs quota disable /var
btrfs quota enable /var
btrfs quota rescan -w /var

# Output: i gruppi quota vengono ricreati e allineati.

Errore: mount: /var: wrong fs type, bad option, bad superblock

Causa: il device LVM è disponibile, ma il filesystem interno è danneggiato o il volume è stato puntato al device sbagliato.

Fix:

blkid
lvdisplay /dev/vgdata/lvvar
btrfs check --readonly /dev/vgdata/lvvar

# Output: identificazione corretta del device e diagnosi in sola lettura prima di qualsiasi repair.

Conclusione

Con storage Linux misto LVM e btrfs, il sintomo visibile raramente dice tutta la verità. Il punto è separare spazio fisico, spazio logico, quota e stato dei subvolume.

Il prossimo passo concreto è semplice: documenta il layout, annota i comandi di verifica e prepara uno snapshot di emergenza prima di toccare quota o balance. In incidente, quei minuti valgono più di un riavvio.

Note: se questo scenario si ripete, valuta di separare dati, log e snapshot su volumi diversi. Riduce l’impatto e rende il rollback molto più prevedibile.