ZimaOS RAID5-expansion har fastnat på 0 %: Kontrollera mdadm och filsystemet

Slutsats: Kontrollera arrayens storlek och filsystemets storlek separat innan du bygger om RAID 5

Det gamla 1.4.1-gränssnittet visade ett förvirrande tillstånd: expansionen nådde 100 %, Storage visade den större totalen på 36 TB, Files visade fortfarande ungefär den gamla användbara kapaciteten och expansionskontrollen förblev låst. Det kan betyda att md-arrayen växte medan filsystemet eller gränssnittet inte slutförde sin egen storleksändring eller uppdatering. Dra inte slutsatsen att operationen lyckades utifrån ett enda kapacitetskort, eller att den misslyckades utifrån ett annat.

ZimaOS RAID5-inställningar som visar fyra 12 TB-diskar med expansionen fast på noll procent efter att tidigare ha nått 100 procent — Efter att expansionen nådde 100 % återgick gränssnittet till statusen Expanding RAID på 0 %, trots att Storage visade den större råkapaciteten.

ZimaOS Files som visar att RAID5-huvudlagringen fortfarande rapporterar den äldre användbara kapaciteten efter expansionen — Vyn Files visade fortfarande det användbara utrymmet före expansionen, vilket skapade osäkerhet kring om endast arrayen hade vuxit eller om även filsystemet hade expanderat.

ZimaOS Storage-översikt som visar RAID5-expansionens status och den större totalen på 36 TB — Storage visade en större total på 36 TB samtidigt som en expansionsstatus fortfarande visades, vilket visar varför gränssnittets kapacitet ensam inte räckte för att verifiera operationen.

Närbild av ZimaOS lagringskapacitet som visar totalt 36 TB efter RAID5-expansion — Närbilden framhäver den nya totala kapaciteten som rapporteras av Storage-gränssnittet efter att den fjärde 12 TB-disken lades till.

Steg 1: Kontrollera antalet RAID-medlemmar och arrayens status

cat /proc/mdstat
sudo mdadm --detail /dev/mdX

Bekräfta att den nya disken är en aktiv medlem, att arrayens status är ren och att ingen omformning eller återställning fortfarande pågår. mdadm-arraystatus är den underliggande referensen för Linux RAID.

Steg 2: Kontrollera blockenhetens och filsystemets storlek

lsblk -f
df -h

Om md-enheten är större men det monterade filsystemet fortfarande rapporterar den gamla storleken, har RAID-lagret expanderat men inte filsystemet. Det är ett annat problem än en misslyckad omformning av diskarna.

Kör inte kommandon för att utöka filsystemet på måfå

EXT4, BTRFS och andra filsystem använder olika verktyg för expansion. Identifiera FSTYPE först. För EXT4 är resize2fs rätt verktyg; för BTRFS fungerar storleksändring av filsystemet på ett annat sätt. Storleksändring av EXT4-filsystem förklarar hur EXT-vägen fungerar.

Aktuella ZimaOS-dokument beskriver RAID 5 som utbyggbart

Aktuellt RAID-material säger uttryckligen att RAID 5 kan utökas genom att fler diskar läggs till över tid. Det innebär att beteendet i den gamla versionen 1.4.1 var ett historiskt expansions- eller gränssnittsproblem, inte ett bevis på att RAID 5-expansion saknar stöd. ZimaOS RAID5-expansion är den moderna utgångspunkten.

Stoppa tunga appar före en omformning som tar flera dagar

Användaren i källan byggde senare om arrayen och lyckades expandera den två gånger efter att ha stoppat containrar och undvikit interaktioner med Files och Storage under operationen. Det är ett användbart praktiskt råd, men bevisar inte att Files var öppet och orsakade det ursprungliga felet. Den säkrare slutsatsen är att minska skrivningar och störningar från gränssnittet under en lång omformning, inte att utse en viss webbläsarflik till grundorsaken.

Starta inte om mitt under en omformning om det inte krävs för återställning

En RAID-omformning är ett ingrepp i lagringen. Om /proc/mdstat visar att förloppet är aktivt bör du låta det slutföras, såvida systemet inte faktiskt håller på att fallera. Plötsligt strömavbrott ökar risken. Använd om möjligt en UPS vid långa expansioner.

Säkerhetskopiera innan du lägger till ytterligare en disk

RAID 5 tål att en medlem fallerar, men en omformning ökar aktiviteten på alla diskar och ersätter inte säkerhetskopiering. ZimaOS-säkerhetskopieringen bör vara klar före en operation som kan ta flera dagar.

Om gränssnittet fortfarande visar Expanding på 0 %

När arrayen och filsystemet har verifierats som felfria och filsystemet ser den nya storleken, blir ett inaktuellt tillstånd i gränssnittet eller tjänsten mer sannolikt. Starta om först när lagringsaktiviteten har upphört och kontrollera sedan igen. Bryt inte arrayen och skapa inte om den enbart för att rensa en förloppsindikator.

Bygg endast om arrayen som sista återställningsåtgärd

Användaren i originalet säkerhetskopierade till slut data, bröt RAID-arrayen och byggde om den. Det fungerade, men är destruktivt. Använd i dag CLI-status, aktuell dokumentation och säkerhetskopior för att avgöra om det faktiskt är arrayen, filsystemet eller gränssnittet som är fel innan du väljer att bygga om. RAID-återställning beskriver återställningens gränser.

Vanliga frågor

Varför visar Storage större kapacitet än Files?

RAID-blockenheten kan ha vuxit medan filsystemet eller Files-gränssnittet fortfarande visar den gamla storleken.

Kan RAID 5 utökas genom att fler diskar läggs till i ZimaOS?

Aktuell ZimaOS-dokumentation säger att RAID 5 kan utökas genom att fler diskar läggs till över tid.

Bör jag stänga Files under expansionen?

Det är klokt att minska aktiva skrivningar, men den gamla tråden bevisar inte att en öppen Files-flik orsakade felet.

När bör jag köra resize2fs?

Endast efter att du har bekräftat att filsystemet är EXT och att den underliggande blockenheten redan är större.

Bör jag bygga om arrayen om gränssnittet har fastnat?

Inte förrän kontroller med mdadm och filsystemet visar ett faktiskt lagringsproblem. En inaktuell förloppsindikator räcker inte.