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

Con così tante parti diverse che costituiscono un tipico stack di stoccaggio, è un miracolo che tutto funzioni affatto. Tuttavia, le cose funzionano bene per la maggior parte del tempo. Le poche volte in cui le cose vanno male, abbiamo bisogno di utility come XFS_Repair per farci uscire dal pasticcio.

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

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

Setup sandbox

Impostiamo un Testbench per eseguire una routine di riparazione XFS invece di utilizzare i dischi reali con dati preziosi su di essa. Se hai già un filesystem rotto, puoi saltare questa sezione e saltare a destra alla successiva. Questo testbench è costituito da una VM Ubuntu a cui è collegato un disco virtuale fornendo memoria grezza. È possibile utilizzare VirtualBox per creare la VM e quindi creare un disco aggiuntivo da collegare alla VM.

Vai alle impostazioni della tua VM e sotto Impostazioni → Archiviazione Sezione È possibile aggiungere un nuovo disco al controller SATA È possibile creare un nuovo disco. Come mostrato di seguito, ma assicurati che la 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 di blocco 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 esso e formatiamola con il filesystem XFS.

Apri l'utilità separata come utente root:

$ separati -a ottimale /dev /sdb

Creiamo prima una tabella di partizione usando mklabel, questo è seguito dalla creazione di una singola partizione dall'intero disco (che ha una dimensione di 107 GB). È possibile verificare che la partizione sia effettuata elencandola usando il comando di stampa:

(separato) Mklabel GPT
(separato) MKPart Primary 0 107
(separato) Stampa
(separato) smettila

Ok, ora possiamo vedere usando LSBLK che esiste un nuovo dispositivo a blocchi sotto il dispositivo SDB, chiamato SDB1.

Formatiamo questo spazio di archiviazione come XFS e lo montiamo nella directory /mnt. Ancora una volta, fai 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 verificare che /dev /sdb1 sia montato su /mnt.

Successivamente scriviamo un sacco di file come dati fittizi a deframment qui:

$ dd if =/dev/urandom di =/mnt/myfile.TXT COUNT = 1024 BS = 1024

Il comando sopra avrebbe scritto un file myfile.txt della dimensione di 1 MB. Se lo desideri, è possibile generare automaticamente più tali file, diffonderli attraverso varie directory all'interno del filesystem XFS (montato AT /MNT) e quindi verificare la frammentazione. Usa Bash o Python o qualsiasi altro del tuo linguaggio di scripting preferito per questo.

Controllare e riparare gli errori

Le corruzioni dei dati possono silenziosamente insinuarsi nei tuoi dischi a tua insaputa. Se un blocco di dati non viene letto e il checksum non è stato confrontato, l'errore potrebbe semplicemente apparire al momento sbagliato. Quando qualcuno sta cercando di accedere ai dati, in tempo reale. Invece, è una buona idea eseguire una scansione completa di tutti i blocchi di dati per il controllo di marciume bit o altri errori frequentemente.

L'utilità XFS_SCRUB dovrebbe svolgere questo compito per il tuo. Ispirato in parte dal comando Scrub di OpenZFS, questa funzione sperimentale è disponibile solo sulla versione 4 di XFSPROGS.15.1-1ubuntu1 che non è una versione stabile. Se rileva erroneamente l'errore, potrebbe indurirti a causare la corruzione dei dati invece di risolverlo! Tuttavia, se si desidera sperimentarlo, puoi usarlo su un filesystem montato usando il comando:

$ xfs_scrub /dev /sdb1

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

$ umount /dev /sdb1

La riparazione di errori è semplice come in esecuzione:

$ xfs_repair /dev /sdb1

I metadati essenziali sono sempre mantenuti come più copie, anche se non stai usando RAID e se qualcosa è andato storto con il superblocco o gli inodi, questo comando può risolvere quel problema per te con ogni probabilità.

Prossimi passi

Se stai vedendo la corruzione dei dati spesso (o anche una volta, se stai eseguendo qualcosa di missione critico) considera la sostituzione dei tuoi dischi in quanto questo potrebbe essere un primo indicatore di un disco che sta per morire.

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