fsck: controllare e riparare un file system

Dopo uno spegnimento brusco, un cavo staccato o un disco che comincia a dare problemi, i file system possono finire in uno stato incoerente: file che non si aprono, cartelle sparite, spazio libero che non torna. Il comando che mette ordine è fsck. È il compagno naturale di mkfs: uno crea il file system, l'altro lo controlla e, se serve, lo ripara.

Cos'è

fsck (file system check) fa parte di util-linux ed è, come mkfs, uno smistatore: riconosce il tipo di file system e lancia il programma giusto, fsck.ext4 (cioè e2fsck), fsck.vfat, fsck.xfs e così via. Puoi quindi chiamare fsck e lasciare che scelga, oppure usare direttamente il programma specifico quando vuoi più controllo.

Cosa fa

Legge le strutture interne del file system (superblocco, inode, mappe dei blocchi, directory) e verifica che siano coerenti tra loro. Se trova differenze, può correggerle, chiedendo conferma una per una o in automatico. I file orfani, cioè quelli che esistono ma non sono più collegati a nessuna cartella, vengono messi nella cartella lost+found con un nome numerico. Va sempre usato su un file system smontato (o montato solo in lettura): controllarlo mentre è in uso può peggiorare le cose.

Come si usa

$ sudo fsck [opzioni] DISPOSITIVO
$ sudo fsck.ext4 [opzioni] DISPOSITIVO

Negli esempi lavoro su immagini di dischi (d.img), come per mkfs. Una precisazione importante: il comando generico fsck accetta dispositivi a blocchi, non file normali; su un file immagine non fa niente e stampa solo la versione. Per questo, sulle immagini, uso e2fsck / fsck.ext4, e mostro fsck su un dispositivo loop (/dev/loop0), che si comporta come un disco vero. Sul tuo sistema sostituisci con la partizione reale, per esempio /dev/sdb1.

Esempio 1: forzare un controllo, solo in lettura

$ sudo fsck.ext4 -fn d.img
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
dati: 14/16384 files (7.1% non-contiguous), 2068/16384 blocks

-n risponde "no" a ogni domanda: il file system non viene modificato, è un controllo in sola lettura. -f forza la verifica anche se il file system sembra pulito (senza -f, un file system "clean" viene saltato). L'ultima riga riassume file usati e blocchi usati; il codice di uscita è 0. Le cinque fasi (pass) sono sempre le stesse: sono la firma di e2fsck.

Esempio 2: vedere cosa farebbe prima di agire

$ sudo fsck -N -f /dev/loop0
fsck from util-linux 2.39.3
[/usr/sbin/fsck.ext4 (1) -- /dev/loop0] fsck.ext4 -f /dev/loop0

Con -N il comando generico non esegue niente: mostra solo quale programma avrebbe lanciato e con quali opzioni. Utile per capire come fsck ha riconosciuto il dispositivo.

Esempio 3: un file system danneggiato, in lettura

$ sudo fsck.ext4 -fn d.img
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'f2.txt' in / (2) has deleted/unused inode 13.  Clear? no

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -2066
Fix? no

Inode bitmap differences:  -13
Fix? no

dati: ********** WARNING: Filesystem still has errors **********
$ echo $?
4

Per provare un danno vero ho cancellato a mano l'inode di un file con debugfs (clri). Con -n e2fsck descrive i problemi, risponde "no" e termina con codice 4, cioè "errori lasciati non corretti". Nell'output ho tolto per brevità la riga sul tipo di voce e quelle sui contatori: sul terminale ne vedrai di più.

Esempio 4: riparare

$ sudo fsck.ext4 -fy d.img
...
Entry 'f2.txt' in / (2) has deleted/unused inode 13.  Clear? yes
...
Block bitmap differences:  -2066
Fix? yes
...
dati: ***** FILE SYSTEM WAS MODIFIED *****
dati: 13/16384 files (7.7% non-contiguous), 2067/16384 blocks
$ echo $?
1

-y risponde "sì" a tutto: ripara senza chiedere. Il codice 1 significa "errori corretti". Dopo la riparazione, un secondo fsck.ext4 -fn torna pulito (codice 0). Qui ho tolto le righe intermedie con i puntini. Attenzione: -y è comodo ma accetta qualsiasi correzione senza che tu possa valutarla. Su dati importanti fai prima una copia dell'immagine (con dd) e ripara la copia, oppure prova prima con -n.

Esempio 5: riparazione automatica, adatta all'avvio

$ sudo fsck.ext4 -fp d.img
dati: Entry 'f2.txt' in / (2) has deleted/unused inode 13.  CLEARED.
dati: 13/16384 files (7.7% non-contiguous), 2067/16384 blocks

-p (preen) ripara solo i problemi "sicuri", senza fare domande, e si ferma con errore se ne trova di più gravi. È la modalità usata all'avvio dal sistema. Su un file system pulito stampa una sola riga: dati: clean, 11/65536 files, 8268/65536 blocks.

Esempio 6: superblocco danneggiato

$ sudo fsck.ext4 -fy big.img
e2fsck 1.47.0 (5-Feb-2023)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
Pass 1: Checking inodes, blocks, and sizes
...
dati: ***** FILE SYSTEM WAS MODIFIED *****

Ho azzerato il superblocco primario di un'immagine da 256 MB: e2fsck ha capito il problema e ha usato da solo una copia di riserva (trying backup blocks). Le copie esistono solo se il file system è abbastanza grande: in un'immagine da 64 MB con un solo gruppo di blocchi non ci sono e il recupero fallisce con Bad magic number e codice 8. Per elencare dove si trovano le copie: dumpe2fs d.img | grep -i "superblock at"; con -b NUMERO puoi indicarne una a mano.

Esempio 7: il comando generico su un dispositivo

$ sudo fsck -f /dev/loop0
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
e2fsck: need terminal for interactive repairs
$ echo $?
8

Questo messaggio l'ho ottenuto perché il mio ambiente non ha un terminale interattivo e il file system aveva errori da riparare; su un terminale vero fsck ti avrebbe fatto le domande una a una. In uno script senza terminale usa -p o -y, oppure -n per il solo controllo. Se il file system è montato, e2fsck si rifiuta:

$ sudo fsck -f /dev/loop0
/dev/loop0 is mounted.
e2fsck: Cannot continue, aborting.

Esempio 8: altri tipi di file system

$ fsck.vfat -n v.img
fsck.fat 4.2 (2021-01-31)
v.img: 1 files, 0/32695 clusters
$ btrfs check b.img
[1/7] checking root items
...
$ fsck.xfs x.img
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

FAT si controlla con fsck.vfat (-n solo lettura, -a riparazione automatica). Btrfs ha un suo strumento, btrfs check, che in lettura è sicuro; la riparazione (--repair) va usata solo come ultima risorsa. XFS è il caso particolare: fsck.xfs non controlla niente e invita a usare xfs_repair (con -n per il solo controllo). Ho provato fsck.vfat, btrfs check e il messaggio di fsck.xfs; xfs_repair l'ho solo avviato, quindi non riporto il suo output completo.

Esempio 9: uso negli script

#!/bin/bash
DEV="$1"
e2fsck -fn "$DEV" > /dev/null 2>&1
rc=$?
if [ "$rc" -eq 0 ]; then
    echo "$DEV: file system pulito"
elif [ $((rc & 4)) -ne 0 ]; then
    echo "$DEV: errori da correggere, smonta e lancia fsck" >&2
else
    echo "$DEV: controllo non riuscito (codice $rc)" >&2
fi
exit "$rc"

Il codice di uscita di fsck è una somma di bit, quindi si controlla con l'operatore & della shell. Lo script esegue un controllo in sola lettura e distingue i casi: su un'immagine sana stampa "file system pulito" (codice 0), su una danneggiata segnala gli errori (codice 4), su un file inesistente dice che il controllo non è riuscito (codice 8). Su un dispositivo reale lancialo con sudo e a file system smontato.

Opzioni utili

• -f: forza il controllo anche se il file system risulta pulito.
• -n: sola lettura, risponde "no" a tutto.
• -y: risponde "sì" a tutto (ripara senza chiedere).
• -p: riparazione automatica dei soli problemi sicuri.
• -t TIPO: limita il controllo a un tipo di file system.
• -N: mostra cosa farebbe, senza eseguire (comando generico).
• -C: mostra una barra di avanzamento (utile sui dischi grandi).
• -b NUMERO: usa un superblocco di riserva (e2fsck).
• -v: output dettagliato con le statistiche finali (e2fsck).
• -A: controlla tutti i file system elencati in /etc/fstab (di solito all'avvio).

Attenzione a

• File system montato: non controllarlo né ripararlo mentre è montato in lettura e scrittura. e2fsck si rifiuta di continuare, ma altri strumenti potrebbero non farlo. Smonta con umount (se è la radice, avvia da una chiavetta live).
• Le riparazioni possono togliere dati: -y cancella voci e inode danneggiati. Prima di riparare un disco con dati importanti, fai una copia dell'immagine o un backup.
• Un disco che si guasta: se gli errori tornano spesso, il problema potrebbe essere il disco, non il file system. Controlla con smartctl prima di insistere con fsck.
• Codici di uscita: 0 nessun errore, 1 errori corretti, 2 serve riavviare, 4 errori non corretti, 8 errore operativo, 16 errore d'uso, 32 operazione annullata. Se più condizioni sono vere i valori si sommano.
• File in lost+found: dopo una riparazione controlla lost+found alla radice del file system: i file recuperati hanno nomi numerici (#12345) e vanno riconosciuti a mano.
• Controlli periodici: in ext4 si possono pianificare con tune2fs -c 30 -i 1m (un controllo ogni 30 montaggi o ogni mese). Per impostazione predefinita sono disattivati.
• Nessun "undo": come per mkfs, ciò che fsck corregge non si può annullare.

Riepilogo