I filesystem sono costruiti su dispositivi di archiviazione storage. Esistono controller RAID e controller del disco che eseguono ciascuno il proprio piccolo pezzo di firmware. Ci sono cache per migliorare le prestazioni. Esistono dischi con dimensioni di settore diverse e ci sono dischi che riporterebbero una dimensione di settore diversa a seconda di come poni la domanda.

Con così tante parti diverse che costituiscono un tipico stack di archiviazione, è un miracolo che tutto funzioni del tutto. Tuttavia, le cose funzionano bene la maggior parte del tempo. Le poche volte in cui le cose vanno male, abbiamo bisogno di utility come xfs_repair per tirarci fuori dai guai.

Le cose possono andare storte quando stai scrivendo un file e l'alimentazione si spegne o c'è un panico del kernel. Anche i dati dormienti su un disco possono decadere nel tempo a causa della modifica della struttura fisica degli elementi di memoria, questo è noto come bit rot. In tutti i casi, abbiamo bisogno di un meccanismo per:

1. Controllare che i dati che vengono letti siano gli stessi dati che sono stati scritti l'ultima volta. Questo viene implementato avendo un checksum per ogni blocco di dati e confrontando il checksum per quel blocco durante la lettura dei dati. Se il checksum corrisponde, i dati non sono stati alterati
2. Un modo per ricostruire i dati corrotti o persi, da un blocco mirror o da un blocco di parità.

Configurazione sandbox

Impostiamo un banco di prova per eseguire una routine di riparazione xfs invece di utilizzare dischi reali con dati preziosi su di esso. Se hai già un filesystem danneggiato, puoi saltare questa sezione e saltare direttamente alla prossima. Questo banco di prova è costituito da una macchina virtuale Ubuntu a cui è connesso un disco virtuale che fornisce spazio di archiviazione non elaborato. Puoi usare VirtualBox per creare la VM e quindi creare un disco aggiuntivo da collegare alla VM.

Vai alle impostazioni della tua VM e sotto Impostazioni → Memoria sezione puoi aggiungere un nuovo disco al controller SATA puoi creare un nuovo disco. Come mostrato di seguito, ma assicurati che la tua VM sia spenta quando lo fai.

Una volta creato il nuovo disco, accendi la VM e apri il terminale. Il comando lsblk elenca tutti i dispositivi a blocchi disponibili.

$ lsblk
sda      8:0    0   60G  0 disco
├─sda1   8:1     0    1M  0 parte
└─sda2   8:2    0   60G  0 parte /
sdb      8:16   0  100G  0 disco
sr0    11:0    1 1024M  0 rom

A parte il dispositivo di blocco principale sda, dove è installato il sistema operativo, ora c'è un nuovo dispositivo sdb. Creiamo rapidamente una partizione da essa e formattiamola con il filesystem XFS.

Apri l'utilità parted come utente root:

$ parted -a ottimale /dev/sdb

Creiamo prima una tabella delle partizioni usando mklabel, seguito dalla creazione di una singola partizione dall'intero disco (che ha una dimensione di 107 GB). Puoi verificare che la partizione sia stata creata elencandola usando il comando print:

(parted) mklabel gpt
(parted) mkpart primary 0 107
(parted) stampa
(separato) esci

Ok, ora possiamo vedere usando lsblk che c'è un nuovo dispositivo a blocchi sotto il dispositivo sdb, chiamato sdb1.

Formattiamo questa memoria come xfs e montiamola nella directory /mnt. Ancora una volta, esegui le seguenti azioni come root:

$ mkfs.xfs /dev/sdb1
$ mount /dev/sdb1 /mnt
$ df -h

L'ultimo comando stamperà tutti i filesystem montati e puoi controllare che /dev/sdb1 sia montato su /mnt.

Quindi scriviamo un mucchio di file come dati fittizi da deframmentare qui:

$ dd if=/dev/urandom of=/mnt/myfile.txt conteggio=1024 bs=1024

Il comando precedente scriverebbe un file miofile.txt di 1 MB di dimensione. Se lo desideri, puoi generare automaticamente più file di questo tipo, distribuirli in varie directory all'interno del filesystem xfs (montato su /mnt) e quindi verificare la frammentazione. Usa bash o python o qualsiasi altro dei tuoi linguaggi di scripting preferito per questo.

Controllo e riparazione degli errori

La corruzione dei dati può insinuarsi silenziosamente nei tuoi dischi a tua insaputa. Se un blocco di dati non viene letto e il checksum non viene confrontato, l'errore potrebbe apparire nel momento sbagliato. Quando qualcuno sta cercando di accedere ai dati, in tempo reale. È invece una buona idea eseguire frequentemente una scansione approfondita di tutti i blocchi di dati per il controllo di bit rot o altri errori.

L'utility xfs_scrub dovrebbe svolgere questo compito per te. Ispirata in parte dal comando scrub di OpenZFS, questa funzionalità sperimentale è disponibile solo su xfsprogs versione 4.15.1-1ubuntu1 che non è una versione stabile. Se rileva erroneamente un errore, potrebbe indurti in errore a causare il danneggiamento dei dati invece di risolverlo! Tuttavia, se vuoi sperimentarlo, puoi usarlo su un filesystem montato usando il comando:

$ xfs_scrub /dev/sdb1

Prima di provare a riparare un filesystem corrotto, dovresti prima smontarlo. Questo serve per impedire alle applicazioni di scrivere inavvertitamente sul filesystem quando dovrebbe essere lasciato da solo.

$ umount /dev/sdb1

Riparare gli errori è semplice come eseguire:

$ xfs_repair /dev/sdb1

I metadati essenziali vengono sempre conservati come copie multiple, anche se non si utilizza RAID e se qualcosa è andato storto con il superblocco o gli inode, questo comando può risolvere il problema con ogni probabilità.

Prossimi passi

Se vedi spesso la corruzione dei dati (o anche una volta, se stai eseguendo qualcosa di fondamentale) prendi in considerazione la sostituzione dei tuoi dischi poiché questo potrebbe essere un indicatore precoce di un disco che sta per morire.

Se un controller si guasta o una scheda RAID ha rinunciato alla vita, nessun software al mondo può riparare il filesystem per te. Non vuoi bollette costose per il recupero dei dati e nemmeno lunghi tempi di inattività, quindi tieni d'occhio quegli SSD e i piatti rotanti!