Filsystemer er bygget på toppen av lagringsenheter. Det er RAID-kontrollere og diskkontrollere som hver kjører sin egen lille firmware. Det er cacher for å forbedre ytelsene. Det er disker med forskjellige sektorstørrelser, og det er disker som rapporterer om 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 fungerer i det hele tatt. Imidlertid fungerer ting bra det meste av tiden. De få gangene 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 kjernepanikk. Selv data som ligger i dvale på en disk, kan forfalle over tid på grunn av den fysiske strukturen til minneelementene kan endre seg, dette er kjent som bitrot. I alle tilfeller trenger vi en mekanisme for:

1. Å sjekke dataene som blir lest er de samme dataene som sist ble skrevet. Dette implementeres ved å ha en kontrollsum for hver datablokk og sammenligne kontrollsummen for den blokken når data blir lest. Hvis kontrollsummen stemmer overens, er ikke dataene endret
2. En måte å rekonstruere korrupte eller tapte data på, enten fra en speilblokk eller fra en paritetsblokk.

Oppsett av sandkasse

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

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

Når den nye disken er opprettet, slår du på VM og åpner terminalen. Kommandoen lsblk lister opp 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 operativsystemet 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 delt verktøy som rotbruker:

$ delt - en optimal / dev / sdb

La oss lage en partisjonstabell først ved hjelp av mklabel, dette blir fulgt av å opprette en enkelt partisjon ut av hele disken (som er 107 GB i størrelse). Du kan bekrefte at partisjonen er laget ved å liste den med utskriftskommandoen:

(skilt) mklabel gpt
(skilt) mkpart primær 0 107
(delt) trykk
(skilt) sluttet

Ok, nå kan vi se ved hjelp av lsblk at det er en ny blokkeringsenhet under sdb-enheten, kalt sdb1.

La oss formatere denne lagringsplassen som xfs og montere den i / mnt-katalogen. Igjen, gjør følgende handlinger som rot:

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

Den siste kommandoen vil skrive ut alle de monterte filsystemene, og du kan sjekke at / dev / sdb1 er montert på / mnt.

Deretter skriver vi en haug med filer som dummy-data for å defragmentere her:

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

Kommandoen ovenfor vil skrive en filfil.tekst på 1 MB størrelse. Hvis du vil, kan du automatisk generere flere slike filer, spre dem over forskjellige kataloger i xfs-filsystemet (montert på / mnt) og deretter se etter fragmentering. Bruk bash eller python eller et hvilket som helst annet av favorittspråket ditt for dette.

Kontrollere og reparere feil

Datakorrupsjoner kan stille krype inn på diskene dine uten at du vet om det. Hvis en datablokk ikke blir lest og kontrollsummen ikke sammenlignes, 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 sjekk av bitrot eller andre feil ofte.

Verktøyet xfs_scrub skal gjøre denne oppgaven for deg. Inspirert delvis av OpenZFS 'skrubbekommando, 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 det! Men 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 demontere det. Dette er for å forhindre at applikasjoner utilsiktet skriver til filsystemet når det skal være alene.

$ umount / dev / sdb1

Å reparere feil er så enkelt som å kjøre:

$ xfs_repair / dev / sdb1

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

Neste skritt

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

Hvis en kontroller svikter, eller et RAID-kort har gitt opp livet, kan ingen programvare i verden reparere filsystemet for deg. Du vil ikke ha dyre datarekonstruksjonsregninger og heller ikke lange nedetid, så hold øye med disse SSD-ene og spinnende platene!