Varför är RAID-kapaciteten fortfarande oförändrad efter att ha bytt ut varje enhet?

Eva Wong

IceWhale author

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.

Why Is RAID Capacity Still Unchanged After Replacing Every Drive? - Zima Store Online

RAID-kapaciteten förblir vanligtvis oförändrad eftersom ett lager i lagringsstacken fortfarande visar den gamla gränsen. Bekräfta att varje ersättning är en aktiv, fullständigt återuppbyggd medlem, och jämför sedan den rapporterade storleken på de fysiska diskarna, medlemspartitionerna, RAID-enheten, volymlagret och det monterade filsystemet i den ordningen. Det första lagret som fortfarande rapporterar den gamla storleken är normalt det lager som måste utökas.

Bekräfta att varje ersättning blev en aktiv medlem

Börja med arrayens status istället för kapacitetsvyn. En större disk som fortfarande listas som reserv, ersättningsmål, återuppbyggnadsenhet eller otillgänglig medlem ökar ännu inte den gemensamma storleken på RAID-gruppen. Anteckna serienummer, roll, användbart sektorsantal, återuppbyggnadstillstånd och felräknare för varje medlem innan du ändrar något.

I en spegling kan kapaciteten normalt inte växa förrän alla medlemmar som definierar speglingen är tillräckligt stora. I paritets-RAID kan varje medlem som deltar i den aktuella geometrin också behöva exponera den större komponentstorleken. Den säkra ersättningssekvensen är att byta ut en disk, vänta på en ren återuppbyggnad, verifiera arrayen och först därefter byta ut nästa disk. ZimaSpaces guide till att ersätta varje spegelmedlem en i taget förklarar varför användbar kapacitet ofta förblir oförändrad under mellanliggande steg.

Hitta det första lagret i lagringen som fortfarande visar den gamla storleken

En NAS kan stapla flera oberoende kapacitetsgränser: fysisk disk, partitionstabell, RAID-medlem, RAID-enhet, krypteringsmappning, LVM-fysisk volym, logisk volym, lagringspool och filsystem. Att byta ut hårdvara ändrar endast det första lagret. Varje lager ovanför måste upptäcka eller informeras om den större gränsen innan den monterade delningen kan använda det extra utrymmet.

Skriv ner storleken som visas på varje lager istället för att upprepade gånger trycka på en "expandera"-knapp. Den korrekta diagnosen är den första övergången där ett lägre lager är större men nästa lager förblir på den gamla storleken.

Första lagret som fortfarande visar den gamla storleken	Sannolik orsak	Nästa säkra kontroll
Ersättningsdisk	Enheten är mindre än förväntat, använder en annan sektorslayout eller är inte helt upptäckt	Jämför modell, serienummer, logisk/fysisk sektorstorlek och totalt antal sektorer
Medlemspartition	Den gamla partitionslayouten klonades utan att förlänga dess slutsektor	Jämför partitionsstart och slutsektorer på varje medlem
RAID-enhet	Arrayen använder fortfarande den gamla komponentstorleken eller har inte slutfört sin utökning	Kontrollera arraystorlek, komponentstorlek, hälsa och stöd för utökning
Volym eller mappning	Nya extent är synliga nedanför men inte tilldelade ovanför	Inspektera kryptering, LVM, thin pool eller lagringspoolgränser
Monterat filsystem	Blockenheten har vuxit men filsystemet har inte gjort det	Använd filsystems-specifik online- eller offline-utökning

Kontrollera om ersättningspartitionerna fortfarande slutar vid den gamla gränsen

Många ersättningsarbetsflöden kopierar den ursprungliga partitionstabellen så att RAID-metadata börjar vid samma offset. Det skyddar justering och medlemsidentitet, men kan också lämna en stor oanvänd region efter den gamla partitionsslutpunkten. Den fysiska disken är större medan RAID-medlemmen som presenteras för arrayen fortfarande är den gamla storleken.

Jämför sektorsantal istället för avrundade terabyte-etiketter. Enheter som säljs med samma nominella kapacitet kan ha något olika användbara sektorsummor, och en undersized ersättningspartition kan förhindra att arrayen väljer en större gemensam komponentstorlek. Återskapa inte partitioner vårdslöst på en aktiv medlem; bevara startsektorn, partitionstypen och RAID-metadatalayouten, och gör endast den plattformsstödda ändringen efter en verifierad säkerhetskopia.

Verifiera att RAID-lagret faktiskt har utökats

Hälsostatus och större medlemmar bevisar inte att RAID-enheten själv har antagit den nya geometrin. Vissa lagringssystem expanderar automatiskt efter sista ersättningen och återuppbyggnaden; andra kräver en separat array-nivå utökning. I Linux md, till exempel, behöver RAID-enheten fortfarande ett explicit utökningsteg efter att de underliggande medlemsenheterna exponerar den större storleken.

Innan du startar en utökning, bekräfta att arrayen är ren, varje förväntad medlem är aktiv, ingen återuppbyggnad eller skurning pågår, och att senaste loggar inte innehåller nya läs-, skriv-, timeout- eller länksfel. En utökning ändrar geometri eller komponentstorlek; den bör inte användas för att dölja ett olöst degraderat tillstånd.

Inspektera kryptering, LVM och lagringspoolgränser ovanför RAID

Om RAID-enheten är större men den logiska volymen förblir oförändrad väntar de extra blocken i ett mellanlager. En krypterad mappning kan behöva skanna om den större enheten. En LVM-fysisk volym kan behöva känna igen nya extent innan volymgruppen kan tilldela dem, och den logiska volymen måste utökas innan filsystemet kan växa.

Hoppa inte direkt till filsystemet bara för att ett kapacitetsverktyg rapporterar ledigt utrymme "någonstans" i stacken. Verifiera storleken som presenteras av varje mappning och volymobjekt. I tunna eller poolade system, skilj på oallokerat poolutrymme från ledigt utrymme i det monterade filsystemet; de är inte utbytbara.

Utöka filsystemet först efter att dess blockenhet är större

Ett filsystem kan bara använda det blockintervall som dess underliggande enhet för närvarande presenterar. Ext4, XFS, Btrfs, ZFS och andra filsystem har olika regler för utökning, monteringskrav och säkerhetskontroller. Identifiera filsystemet och lagringsstacken först, och använd sedan dess stödda procedur istället för att låna ett kommando från en annan plattform.

ZFS är ett bra exempel på varför det sista steget kan vara implementeringsspecifikt. Efter att alla spegelmedlemmar är utbytta kan en ZFS-spegel fortfarande behöva att den nya enhetsstorleken utökas innan poolen exponerar utrymmet. Btrfs kan på liknande sätt kräva att den större enhetsgränsen känns igen även om ersättningen slutfördes framgångsrikt. Rätt åtgärd beror på vilket lager som äger medlemsenheterna.

Stoppa när plattformen inte kan utöka den befintliga layouten på plats

Vissa RAID-kontroller, apparatlayouter, partitionsscheman och filsystem kan inte växa den aktuella konfigurationen på plats. Andra kan bara expandera vissa RAID-nivåer eller kräver att alla medlemmar matchar exakt. Om administrationsgränssnittet inte erbjuder någon stödd utökningsväg, tvinga inte kommandon från en annan lagringsstack bara för att diskstorlekarna ser liknande ut.

Stoppa och planera en säkerhetskopiering och återuppbyggnadsmigrering när medlems-historik krockar, arrayen är degraderad, hälsoräknare ökar, partitionslayouten inte kan ändras säkert eller plattformen inte dokumenterar någon metod för utökning på plats. Efter en stödd utökning, verifiera den nya storleken på varje lager, kör plattformens integritetskontroll, bekräfta normal applikationsåtkomst och bevara status före och efter som ny baslinje.