Filsystemer er bygget oven på lagerenheder. Der er RAID-controllere og diskcontrollere, der hver kører sit eget lille stykke firmware. Der er cacher for at forbedre præstationerne. Der er diske med forskellige sektorstørrelser, og der er diske, der rapporterer om en anden sektorstørrelse, afhængigt af hvordan du stiller spørgsmålet.

Med så mange forskellige dele, der udgør en typisk opbevaringsstabel, er det et mirakel, at noget overhovedet fungerer. Ting fungerer dog godt det meste af tiden. De få gange, når ting går galt, har vi brug for hjælpeprogrammer som xfs_repair for at få os ud af rodet.

Ting kan gå galt, når du skriver en fil, og strømmen går ud, eller der er en kernepanik. Selv data, der ligger i dvale på en disk, kan henfalde over tid på grund af den fysiske struktur af hukommelseselementer kan ændre sig, dette kaldes bitrot. I alle tilfælde har vi brug for en mekanisme til:

1. Kontrol af de data, der læses, er de samme data, som sidst blev skrevet. Dette implementeres ved at have et kontrolsum for hver blok af data og sammenligne kontrolsummen for denne blok, når data læses. Hvis kontrolsummen stemmer overens, er dataene ikke ændret
2. En måde at rekonstruere korrupte eller mistede data på, enten fra en spejlblok eller fra en paritetsblok.

Opsætning af sandkasse

Lad os opsætte en testbænk til at køre en xfs-reparationsrutine i stedet for at bruge faktiske diske med værdifulde data på. Hvis du allerede har et ødelagt filsystem, kan du springe dette afsnit over og springe højre hoved til det næste. Denne testbænk består af en Ubuntu VM, som en virtuel disk er forbundet med, hvilket giver rå lagring. Du kan bruge VirtualBox til at oprette den virtuelle computer og derefter oprette en ekstra disk til at vedhæfte den til den virtuelle computer.

Gå bare til din VM's indstillinger og derunder Indstillinger → Opbevaring sektion kan du tilføje en ny disk til SATA-controlleren, du kan oprette en ny disk. Som vist nedenfor, men sørg for, at din VM er slukket, når du gør dette.

Når den nye disk er oprettet, skal du tænde den virtuelle computer og åbne terminalen. Kommandoen lsblk viser alle tilgængelige blokkenheder.

$ 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

Bortset fra hovedbloksenheden sda, hvor operativsystemet er installeret, er der nu en ny SDB-enhed. Lad os hurtigt oprette en partition fra den og formatere den med XFS-filsystem.

Åbn opskilt værktøj som rodbruger:

$ skilt -en optimal / dev / sdb

Lad os først oprette en partitionstabel ved hjælp af mklabel, dette efterfølges af at oprette en enkelt partition ud af hele disken (som er 107 GB i størrelse). Du kan kontrollere, at partitionen er lavet, ved at angive den ved hjælp af kommandoen print:

(skilt) mklabel gpt
(skilt) mkpart primær 0 107
(skilt) print
(skilt) afslutte

Okay, nu kan vi se ved hjælp af lsblk, at der er en ny blokkenhed under sdb-enheden, kaldet sdb1.

Lad os formatere dette lager som xfs og montere det i / mnt-biblioteket. Igen skal du gøre følgende som root:

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

Den sidste kommando udskriver alle monterede filsystemer, og du kan kontrollere, at / dev / sdb1 er monteret på / mnt.

Dernæst skriver vi en masse filer som dummy-data til defragmentering her:

$ dd hvis = / dev / urandom af = / mnt / myfile.txt-antal = 1024 bs = 1024

Ovenstående kommando ville skrive en fil myfile.txt på 1 MB størrelse. Hvis du vil, kan du automatisk generere flere sådanne filer, sprede dem over forskellige mapper inde i xfs-filsystemet (monteret på / mnt) og derefter kontrollere for fragmentering. Brug bash eller python eller et hvilket som helst andet af dit foretrukne script-sprog til dette.

Kontrol og reparation af fejl

Datakorruptioner kan lydløst krybe ind på dine diske uden din viden. Hvis en datablok ikke læses, og kontrolsummen ikke sammenlignes, kan fejlen måske bare dukke op på det forkerte tidspunkt. Når nogen prøver at få adgang til dataene i realtid. I stedet er det en god ide at køre en grundig scanning af alle datablokke til kontrol af bitrot eller andre fejl ofte.

Værktøjet xfs_scrub skal udføre denne opgave for din. Inspireret delvist af OpenZFS 'skrubbekommando, er denne eksperimentelle funktion kun tilgængelig på xfsprogs version 4.15.1-1ubuntu1, som ikke er en stabil udgivelse. Hvis det fejlagtigt registrerer fejl, kan det vildlede dig til at forårsage datakorruption i stedet for at rette det! Men hvis du vil eksperimentere med det, kan du bruge det på et monteret filsystem ved hjælp af kommandoen:

$ xfs_scrub / dev / sdb1

Før du prøver at reparere et korrupt filsystem, skal du først afmontere det. Dette er for at forhindre, at applikationer utilsigtet skriver til filsystemet, når det formodes at være alene.

$ umount / dev / sdb1

Reparation af fejl er så simpelt som at køre:

$ xfs_repair / dev / sdb1

Væsentlige metadata opbevares altid som flere kopier, selvom du ikke bruger RAID, og ​​hvis noget er gået galt med superblokken eller inoder, kan denne kommando med al sandsynlighed løse problemet for dig.

Næste skridt

Hvis du ofte ser datakorruption (eller endda en gang, hvis du kører noget missionskritisk), skal du overveje at udskifte dine diske, da dette kan være en tidlig indikator for en disk, der er ved at dø.

Hvis en controller fejler, eller et RAID-kort har givet op i livet, kan ingen software i verden reparere filsystemet til dig. Du vil ikke have dyre datagendannelsesregninger, og du vil heller ikke have lange nedetid, så hold øje med disse SSD'er og spindende plader!