Filsystemer er bygget på toppen av lagringsenheter. Det er RAID -kontrollere og diskkontrollere som hver kjører sitt eget lille firmware. Det er hurtigbuffer for å forbedre forestillingene. Det er disker med forskjellige sektorstørrelser, og det er disker som vil rapportere en annen sektorstørrelse avhengig av hvordan du stiller spørsmålet.

Med så mange forskjellige deler som utgjør en typisk lagringsstabel, er det et mirakel at alt i det hele tatt fungerer. Imidlertid fungerer ting bra mesteparten av tiden. De få ganger når ting går galt, trenger vi verktøy som XFS_Repair for å få oss ut av rotet.

Ting kan gå galt når du skriver en fil og strømmen går ut, eller det er en kjernepanikk. Selv data som sitter i dvale på en disk kan forfalle over tid på grunn av den fysiske strukturen til minneelementer kan endre seg, dette er kjent som bit råt. I alle tilfeller trenger vi en mekanisme for:

1. Å sjekke dataene som leses er de samme dataene som sist ble skrevet. Dette implementeres ved å ha en sjekksum for hver datablokk og sammenligne sjekksummen for den blokken når data leses. Hvis sjekksumen samsvarer, har ikke dataene blitt endret
2. En måte å rekonstruere de korrupte eller tapte dataene, enten fra en speilblokk eller fra en paritetsblokk.

Sandkasseoppsett

La oss sette opp en testbench for å kjøre en XFS -reparasjonsrutine i stedet for å bruke faktiske disker med verdifulle data på den. Hvis du allerede har et ødelagt filsystem, kan du hoppe over denne delen og hoppe til høyre til det neste. Denne testbenken består av en Ubuntu VM som en virtuell disk er tilkoblet med rålagring. Du kan bruke VirtualBox til å lage VM og deretter opprette en ekstra disk for å feste til VM.

Bare gå til VMs innstillinger og under Innstillinger → lagring Seksjon Du kan legge til en ny disk til SATA -kontrolleren. Du kan opprette en ny disk. Som vist nedenfor, men sørg for at VM -en din er slått av når du gjør dette.

Når den nye disken er opprettet, slå på VM og åpne opp terminalen. Kommandoen LSBLK viser alle tilgjengelige blokkenheter.

$ LSBLK
SDA 8: 0 0 60G 0 Disk
├─Sda1 8: 1 0 1m 0 Del
└─Sda2 8: 2 0 60g 0 Del /
SDB 8:16 0 100G 0 Disk
SR0 11: 0 1 1024M 0 ROM

Bortsett fra hovedblokkenheten SDA, Der OS er installert, er det nå en ny SDB -enhet. La oss raskt lage en partisjon fra den og formatere den med XFS -filsystem.

Åpne opp skilt verktøy som rotbruker:

$ delt -en optimal /dev /sdb

La oss lage en partisjonstabell først ved hjelp av Mklabel, dette blir fulgt av å lage en enkelt partisjon ut av hele disken (som er 107 GB i størrelse). Du kan bekrefte at partisjonen er gjort ved å oppgi den ved hjelp av utskriftskommando:

(skilt) mklabel gpt
(skilt) mkpart primær 0 107
(skilt) utskrift
(skilt) slutte

Ok, nå kan vi se ved hjelp av LSBLK at det er en ny blokkenhet under SDB -enheten, kalt SDB1.

La oss formatere denne lagringen som XFS og montere den i /MNT -katalogen. Igjen, gjør følgende handlinger som root:

$ MKFS.XFS /Dev /SDB1
$ mount /dev /sdb1 /mnt
$ df -h

Den siste kommandoen vil skrive ut alle monterte filsystemer, og du kan sjekke at /dev /sdb1 er montert AT /MNT.

Neste gang skriver vi en haug med filer som dummy data for å defragmentere her:

$ dd if =/dev/urandom av =/mnt/myfile.TXT Count = 1024 BS = 1024

Kommandoen ovenfor ville skrive en fil myfil.txt av 1 MB størrelse. Hvis du vil, kan du automatisk generere flere slike filer, spre dem over forskjellige kataloger i XFS -filsystemet (montert AT /MNT) og deretter se etter fragmentering. Bruk bash eller python eller noe annet av ditt favoritt skriptspråk for dette.

Kontrollere og reparere feil

Datakorrupsjoner kan lydløst krype inn i skivene dine uten din kunnskap. Hvis en datablokk ikke leses og sjekksummen ikke sammenlignet, kan feilen bare dukke opp til feil tid. Når noen prøver å få tilgang til dataene, i sanntid. I stedet er det en god idé å kjøre en grundig skanning av alle datablokkene for sjekken av bitrot eller andre feil ofte.

Verktøyet xfs_scrub er ment å gjøre denne oppgaven for din. Inspirert delvis av OpenZFS 'Scrub Command, er denne eksperimentelle funksjonen bare tilgjengelig på XFSProgs versjon 4.15.1-1ubuntu1 som ikke er en stabil utgivelse. Hvis det feilaktig oppdager feil, kan det villede deg til å forårsake datakorrupsjon i stedet for å fikse den! Imidlertid, hvis du vil eksperimentere med det, kan du bruke det på et montert filsystem ved hjelp av kommandoen:

$ xfs_scrub /dev /sdb1

Før du prøver å reparere et korrupt filsystem, må du først avmontere det. Dette for å stoppe applikasjoner fra å utilsiktet skrive til filsystemet når det er ment å være i fred.

$ umount /dev /sdb1

Reparasjon av feil er så enkelt som å løpe:

$ XFS_REPAIR /DEV /SDB1

Viktige metadata holdes alltid som flere eksemplarer, selv om du ikke bruker RAID, og ​​hvis noe har gått galt med superblokken eller inodene, kan denne kommandoen løse det problemet for deg i all sannsynlighet.

Neste skritt

Hvis du ser datakorrupsjon ofte (eller til og med en gang, hvis du kjører noe oppdragskritisk), bør du vurdere å erstatte diskene dine, da dette kan være en tidlig indikator på en disk som er i ferd med å dø.

Hvis en kontroller mislykkes, eller et raidkort har gitt opp livet, kan ingen programvare i verden reparere filsystemet for deg. Du vil ikke ha dyre regninger for datainnretting, og du vil heller ikke ha lange nedganger, så følg med på disse SSD -ene og spinnende tallerkener!