Vad bör du kontrollera när RAID-kapaciteten inte ökar efter att en enhet har bytts ut?

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

RAID-kapaciteten förblir vanligtvis oförändrad eftersom ett lager fortfarande rapporterar den gamla gränsen. Bekräfta återuppbyggnaden, medlemsstorlekar, array-geometri, partitionering och filsystem i den ordningen.

Att byta ut diskar är bara hårdvarusteget. En NAS kan innehålla flera staplade storleksgränser, och varje lager måste exponera den större gränsen innan nästa lager kan använda den. Den säkraste diagnosen börjar med statuskontroller i skrivskyddat läge, identifierar det första lagret som fortfarande är litet och utökar endast det lagret istället för att upprepa utbytet.

Bekräfta att varje utbyte är helt integrerat

Kapaciteten kan inte öka medan en spegel- eller paritetsgrupp fortfarande innehåller en ursprunglig mindre medlem, en reserv som inte blivit aktiv eller en ersättning som fortfarande återuppbyggs. Arrayen använder normalt endast den gemensamma kapacitet som finns tillgänglig över medlemmarna som definierar dess geometri.

En disk kan visas i NAS-inventariet utan att vara en synkroniserad medlem. Jämför arraystatus, återuppbyggnadstillstånd, medlemsroll, serienummer och rapporterad enhetsstorlek istället för att anta att en upptäckt disk har slutfört utbytesprocessen.

Vänta tills varje nödvändigt utbyte och återuppbyggnad eller resilvering är klar utan nya fel. Om en medlem saknas, är felaktig eller mindre än förväntat, lös det tillståndet innan du försöker något utökningskommando eftersom arraylagret fortfarande har en giltig anledning att bevara den gamla storleken.

Kontrollera den användbara storleken på varje medlemsenhet

En större fysisk enhet kan fortfarande visa en partition med gammal storlek eller en registrerad komponentgräns för RAID. Jämför hela diskens kapacitet, partitionens slutsektorer och de exakta blockenheter som listas som arraymedlemmar.

En större version 1.x-medlem kan behålla sin registrerade komponentgräns även efter att den fysiska disken har bytts ut. Utökning till maximal komponentstorlek sker först efter att alla aktiva medlemmar kan stödja det.

Återskapa inte en partition bara för att dess visade storlek är gammal. Registrera först startsektorn, partitionstyp, RAID UUID och medlemsserienummer; använd sedan den plattformsstödda expansionsmetoden som bevarar befintlig startposition och metadata.

Verifiera att RAID-lagret har utökats

När varje medlem är större men RAID-blockenheten inte är det, har array-geometrin inte utökats. Den nödvändiga åtgärden beror på om stacken är md RAID, ZFS, Btrfs, en hårdvarukontroller eller en NAS-hanterad lagringspool.

För md RAID startar ändring av aktiv komponentstorlek en resynkronisering av den nyligen exponerade regionen. I en ZFS-spegel blir utrymme tillgängligt först efter att varje enhet i spegelgruppen har bytts ut, och expansion kan kräva autoexpand eller en explicit online-expansion.

Använd hanteringsgränssnittet eller kommandot som tillhör den faktiska RAID-implementeringen. Avbryt om arrayen rapporterar en omformning, degraderat tillstånd, icke-stödd layoutändring eller medlemsstorleksavvikelse; dessa tillstånd måste lösas innan den nya gränsen kan litas på.

Kontrollera om det finns ett partition- eller volymlager ovanför RAID

Även efter att RAID-enheten växer kan en partitionstabell, LVM-fysisk volym, logisk volym, krypterad mappning eller lagringspoolallokering fortfarande sluta vid den tidigare sektorn. Filsystemet kan inte se block som ett mellanlager inte har tilldelat det.

Följ den monterade sökvägen nedåt med plattformens blockenhetsvy och jämför storlekar vid varje steg. Det första objektet som förblir litet är lagret som ska utökas; att ändra ett högre lager först kommer antingen att misslyckas eller lämna det nya utrymmet oallokerat.

Utöka en gräns i taget och kontrollera nästa lager innan du fortsätter. Denna stegvisa metod skapar en tydlig återställningspunkt och förhindrar att ett kommando avsett för ett filsystem av misstag tillämpas på en RAID-medlem eller partition.

Utöka filsystemet först efter att blockenheten har vuxit

Ett filsystem expanderar inte nödvändigtvis när dess underliggande RAID-enhet blir större. Bekräfta att det monterade filsystemet fortfarande rapporterar den gamla storleken medan dess innehållande blockenhet nu rapporterar den nya storleken.

För ext2, ext3 och ext4 förväntar sig filsystemets storleksändringsverktyg att partitionen eller den logiska enheten först förstoras. XFS följer samma lagerordning, och en XFS-utökning expanderar ett monterat filsystem till kapacitet som redan exponeras av enheten.

Använd det filsystems-specifika utökningskommandot först efter att ha kontrollerat enhetsväg, monteringspunkt, stöd för online-tillstånd och senaste backup. En lyckad RAID-expansion med oförändrat filsystem är ofullständig, men det är säkrare än att gissa på fel lager.

Ta hänsyn till filsystems-specifik enhetsstorleksändring

Vissa filsystem hanterar flera enheter direkt, så deras utbytes- och storleksändringssteg matchar inte en konventionell RAID-plus-filsystem-stack. Btrfs är ett vanligt exempel: att byta ut en enhet och exponera dess fulla nya kapacitet är separata operationer.

Att byta ut en Btrfs-enhet mot en större mål-enhet exponerar inte automatiskt de tillagda blocken för filsystemet. En separat enhetsstorleksändring förklarar varför utbytet kan slutföras utan problem medan rapporterad kapacitet förblir oförändrad.

Identifiera om filsystemet självt äger enhetsuppsättningen innan du använder mdadm, partition eller LVM-instruktioner. Att blanda procedurer från olika lagringsstackar är ett av de snabbaste sätten att förvandla ett enkelt kapacitetsproblem till ett metadatafel.

Använd en lager-för-lager kapacitetskontroll

Det avgörande testet är att skriva ner den rapporterade storleken på varje lager från fysisk disk till monterat filsystem. Kapaciteten bör öka monotoniskt genom stacken, med förväntade minskningar för RAID-redundans, metadata, reserverade block och enhetsomvandling.

Om de fysiska diskarna är större men medlemspartitionerna inte är det, åtgärda partitionslagret. Om RAID-enheten är större men den logiska volymen inte är det, utöka volymen. Om varje blocklager är större men det monterade filsystemet inte är det, utför filsystemets utökningssteg.

Stoppa när två intilliggande lager inte överensstämmer på ett oförklarligt sätt eller när någon hälsoräknare ökar under expansionen. Spara statusutdata och säkerhetskopior innan du ändrar geometrin, eftersom den första oförklarade gränsen är en diagnostisk ledtråd snarare än en anledning att tvinga nästa operation.

Första lagret som fortfarande visar gammal storlek Sannolik orsak Nästa säkra kontroll
Medlemspartition Utbytet behöll gammalt partitionsslut Jämför start- och slutsektorer
RAID-enhet Arraykomponentens storlek utökades inte Kontrollera hälsotillstånd och stöd för utökning
Volym eller mappning Nya extentområden är fortfarande oallokerade Inspektera PV, LV, pool eller krypteringsstorlek
Monterat filsystem Filsystemets utökningssteg kördes inte Använd det filsystems-specifika verktyget

Support och tips

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.