Filsystem är byggda ovanpå lagringsenheter. Det finns RAID-kontroller och diskkontroller som alla kör sin egen lilla fast programvara. Det finns cachar för att förbättra prestanda. Det finns skivor med olika sektorstorlekar och det finns skivor som rapporterar en annan sektorstorlek beroende på hur du ställer frågan.

Med så många olika delar som utgör en typisk lagringsstack är det ett mirakel att allt fungerar alls. Saker fungerar dock bra för det mesta. De få gånger när saker går fel behöver vi verktyg som xfs_repair för att få oss ur röran.

Saker kan gå fel när du skriver en fil och strömmen släcks eller om det finns en kärnpanik. Även data som ligger vilande på en skiva kan förfalla över tid på grund av att minneselementens fysiska struktur kan förändras, detta kallas bitrot. I alla fall behöver vi en mekanism för:

1. Kontroll av data som läses är samma data som senast skrevs. Detta implementeras genom att ha en kontrollsumma för varje datablock och jämföra kontrollsumman för det blocket när data läses. Om kontrollsumman matchar har uppgifterna inte ändrats
2. Ett sätt att rekonstruera korrupta eller förlorade data, antingen från ett spegelblock eller från ett paritetsblock.

Sandbox-installation

Låt oss ställa in en testbänk för att köra en xfs-reparationsrutin istället för att använda faktiska diskar med värdefull data på. Om du redan har ett trasigt filsystem kan du hoppa över det här avsnittet och hoppa till höger till nästa. Denna testbänk består av en virtuell Ubuntu-dator som en virtuell disk är ansluten för att ge rå lagring. Du kan använda VirtualBox för att skapa den virtuella datorn och sedan skapa en ytterligare disk att bifoga till den virtuella datorn.

Gå bara till din VM: s inställningar och under Inställningar → Lagring avsnitt kan du lägga till en ny disk till SATA-styrenheten kan du skapa en ny disk. Som visas nedan, men se till att din virtuella dator är avstängd när du gör det.

När den nya disken har skapats slår du på den virtuella datorn och öppnar terminalen. Kommandot lsblk listar alla tillgängliga blockenheter.

$ 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 från huvudblockenheten sda, där operativsystemet är installerat finns det nu en ny SDB-enhet. Låt oss snabbt skapa en partition från den och formatera den med XFS-filsystem.

Öppna delat verktyg som rotanvändare:

$ parted -a optimal / dev / sdb

Låt oss skapa en partitionstabell först med mklabel, detta följs av att skapa en enda partition av hela disken (som är 107 GB i storlek). Du kan verifiera att partitionen är skapad genom att lista den med utskriftskommandot:

(delad) mklabel gpt
(delad) mkpart primär 0 107
(delad) tryck
(parted) slutade

Okej, nu kan vi se med hjälp av lsblk att det finns en ny blockeringsenhet under sdb-enheten, kallad sdb1.

Låt oss formatera denna lagring som xfs och montera den i / mnt-katalogen. Återigen gör följande åtgärder som root:

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

Det sista kommandot skriver ut alla monterade filsystem och du kan kontrollera att / dev / sdb1 är monterad på / mnt.

Därefter skriver vi en massa filer som dummydata för att defragmentera här:

$ dd if = / dev / urandom of = / mnt / myfile.txtantal = 1024 bs = 1024

Ovanstående kommando skulle skriva en fil myfile.txt på 1 MB storlek. Om du vill kan du automatiskt generera fler sådana filer, sprida dem över olika kataloger i xfs-filsystemet (monterad på / mnt) och sedan leta efter fragmentering. Använd bash eller python eller något annat av ditt favoritskriptspråk för detta.

Kontroll och reparation av fel

Datakorruption kan tyst krypa in på dina diskar utan din vetskap. Om ett datablock inte läses och kontrollsumman inte jämförs kan felet bara dyka upp vid fel tidpunkt. När någon försöker komma åt data i realtid. Istället är det en bra idé att köra en grundlig genomsökning av alla datablock för kontroll av bitrutt eller andra fel ofta.

Verktyget xfs_scrub ska göra den här uppgiften för din. Inspirerad delvis av OpenZFS skrubbkommando är den här experimentella funktionen endast tillgänglig på xfsprogs version 4.15.1-1ubuntu1 som inte är en stabil version. Om det fel upptäcker fel kan det vilseleda dig till att orsaka dataskada istället för att fixa det! Men om du vill experimentera med det kan du använda det på ett monterat filsystem med kommandot:

$ xfs_scrub / dev / sdb1

Innan du försöker reparera ett korrupt filsystem måste du först avmontera det. Detta för att förhindra att applikationer oavsiktligt skriver till filsystemet när det ska lämnas i fred.

$ umount / dev / sdb1

Att reparera fel är lika enkelt som att köra:

$ xfs_repair / dev / sdb1

Viktiga metadata hålls alltid som flera kopior, även om du inte använder RAID och om något har gått fel med superblocket eller inoder kan det här kommandot med all sannolikhet lösa problemet för dig.

Nästa steg

Om du ser datakorruption ofta (eller till och med en gång, om du kör något missionskritiskt), överväga att byta ut dina diskar, eftersom det här kan vara en tidig indikator på en disk som håller på att dö.

Om en kontroller misslyckas, eller om ett RAID-kort har gett liv, kan ingen programvara i världen reparera filsystemet åt dig. Du vill inte ha dyra datarekonstruktioner och inte heller långa driftstopp, så håll ett öga på dessa SSD-enheter och snurrplattor!