Bestandssystemen zijn bovenop opslagapparaten gebouwd. Er zijn RAID-controllers en schijfcontrollers die elk hun eigen stukje firmware hebben. Er zijn caches om de prestaties te verbeteren. Er zijn schijven met verschillende sectorgroottes en er zijn schijven die een andere sectorgrootte rapporteren, afhankelijk van hoe je de vraag stelt.

Met zoveel verschillende onderdelen die een typische opslagstapel vormen, is het een wonder dat alles überhaupt werkt. Meestal werken de dingen echter goed. De paar keer dat er iets misgaat, hebben we hulpprogramma's zoals xfs_repair nodig om ons uit de problemen te krijgen.

Er kunnen dingen fout gaan als je een bestand schrijft en de stroom uitvalt of er is een kernel panic. Zelfs gegevens die slapend op een schijf staan, kunnen na verloop van tijd vervallen omdat de fysieke structuur van geheugenelementen kan veranderen, dit staat bekend als bitrot. In alle gevallen hebben we een mechanisme nodig voor:

1. Controleren of de gegevens die worden gelezen dezelfde gegevens zijn die het laatst zijn geschreven. Dit wordt geïmplementeerd door een controlesom te hebben voor elk gegevensblok en de controlesom voor dat blok te vergelijken wanneer gegevens worden gelezen. Als de controlesom overeenkomt, zijn de gegevens niet gewijzigd
2. Een manier om de corrupte of verloren gegevens te reconstrueren, hetzij vanuit een spiegelblok of vanuit een pariteitsblok.

Sandbox-configuratie

Laten we een testbank opzetten om een ​​xfs-reparatieroutine uit te voeren in plaats van echte schijven met waardevolle gegevens erop te gebruiken. Als je al een kapot bestandssysteem hebt, kun je deze sectie overslaan en meteen naar de volgende gaan. Deze testbench bestaat uit een Ubuntu-VM waarop een virtuele schijf is aangesloten die onbewerkte opslag biedt. U kunt VirtualBox gebruiken om de VM te maken en vervolgens een extra schijf maken om aan de VM te koppelen.

Ga gewoon naar de instellingen van uw VM en onder Instellingen → Opslag sectie kunt u een nieuwe schijf toevoegen aan de SATA-controller, u kunt een nieuwe schijf maken. Zoals hieronder weergegeven, maar zorg ervoor dat uw VM is uitgeschakeld wanneer u dit doet.

Zodra de nieuwe schijf is gemaakt, schakelt u de VM in en opent u de terminal. Het bevel lsblk geeft een overzicht van alle beschikbare blokapparaten.

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

Afgezien van het hoofdblokapparaat sda, waar het besturingssysteem is geïnstalleerd, is er nu een nieuw sdb-apparaat. Laten we er snel een partitie van maken en deze formatteren met het XFS-bestandssysteem.

Open het parted-hulpprogramma als de rootgebruiker:

$ parted -a optimale /dev/sdb

Laten we eerst een partitietabel maken met mklabel, dit wordt gevolgd door een enkele partitie van de hele schijf te maken (die 107 GB groot is). U kunt controleren of de partitie is gemaakt door deze op te sommen met de printopdracht:

(gescheiden) mklabel gpt
(parted) mkpart primair 0 107
(gescheiden) print
(scheidde) stoppen

Oké, nu kunnen we met lsblk zien dat er een nieuw blokapparaat onder het sdb-apparaat is, genaamd sdb1.

Laten we deze opslag formatteren als xfs en deze koppelen aan de map /mnt. Voer opnieuw de volgende acties uit als root:

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

Het laatste commando zal alle aangekoppelde bestandssystemen afdrukken en je kunt controleren of /dev/sdb1 is aangekoppeld op /mnt.

Vervolgens schrijven we een aantal bestanden als dummy-gegevens om hier te defragmenteren:

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

De bovenstaande opdracht zou een bestand mijnbestand schrijven.txt van 1 MB groot. Als u wilt, kunt u automatisch meer van dergelijke bestanden genereren, deze over verschillende mappen in het xfs-bestandssysteem (aangekoppeld op /mnt) verspreiden en vervolgens controleren op fragmentatie. Gebruik hiervoor bash of python of een andere van je favoriete scripttaal.

Fouten controleren en herstellen

Gegevensbeschadigingen kunnen stilletjes uw schijven binnensluipen zonder uw medeweten. Als een gegevensblok niet wordt gelezen en de controlesom niet wordt vergeleken, kan de fout op het verkeerde moment verschijnen. Wanneer iemand in realtime toegang probeert te krijgen tot de gegevens. In plaats daarvan is het een goed idee om regelmatig een grondige scan van alle gegevensblokken uit te voeren om bitrot of andere fouten te controleren.

Het hulpprogramma xfs_scrub zou deze taak moeten doen voor uw. Gedeeltelijk geïnspireerd door het scrub-commando van OpenZFS, is deze experimentele functie alleen beschikbaar op xfsprogs versie 4.15.1-1ubuntu1 wat geen stabiele release is. Als het ten onrechte een fout detecteert, kan het u misleiden om gegevenscorruptie te veroorzaken in plaats van het te repareren! Als je er echter mee wilt experimenteren, kun je het op een gemount bestandssysteem gebruiken met het commando:

$ xfs_scrub /dev/sdb1

Voordat u een beschadigd bestandssysteem probeert te repareren, moet u het eerst ontkoppelen. Dit is om te voorkomen dat applicaties per ongeluk naar het bestandssysteem schrijven wanneer het met rust gelaten zou moeten worden.

$ umount /dev/sdb1

Fouten herstellen is net zo eenvoudig als uitvoeren:

$ xfs_repair /dev/sdb1

Essentiële metadata wordt altijd bewaard als meerdere kopieën, zelfs als u geen RAID gebruikt en als er iets mis is gegaan met het superblok of de inodes, dan kan deze opdracht dat probleem naar alle waarschijnlijkheid voor u oplossen.

Volgende stappen

Als u vaak gegevenscorruptie ziet (of zelfs één keer, als u iets missiekritiek uitvoert), overweeg dan om uw schijven te vervangen, omdat dit een vroege indicator kan zijn van een schijf die op het punt staat dood te gaan.

Als een controller uitvalt of een RAID-kaart het leven heeft opgegeven, kan geen enkele software ter wereld het bestandssysteem voor u repareren. U wilt geen dure rekeningen voor gegevensherstel en ook geen lange uitvaltijden, dus houd die SSD's en draaiende schijven in de gaten!