ZimaOS RAID 1-expansion: guide för att utöka med en större enhet

Källan visar att byte av båda RAID 1-medlemmarna mot större diskar inte automatiskt utökar det användbara filsystemet. En användare bytte framgångsrikt ut två diskar på 500 GB mot diskar på 1 TB, en i taget, och lät ZimaOS bygga om arrayen efter varje byte. Då var båda fysiska medlemmarna på 1 TB, men RAID-enheten och Btrfs-filsystemet exponerade fortfarande endast den gamla kapaciteten på 500 GB.

På ZimaOS+ 1.5.4 slutförde användaren därefter utökningen via SSH med mdadm --grow /dev/md0 --size=max, väntade på den efterföljande återställningen/omsynkroniseringen och körde slutligen btrfs filesystem resize max mot det monterade filsystemet. De rapporterade att GUI:t och df och visade sedan den större kapaciteten. Detta är en stark community-verifiering, men det är fortfarande ett manuellt CLI-arbetsflöde – inte en aktuell IceWhale GUI-procedur.

Säkerhetskopiera innan du börjar utöka kapaciteten

RAID 1 skyddar mot att en medlem går sönder; det skyddar inte mot operatörsmisstag, skador på arraymetadata, fel i filsystemet eller problem med en andra disk under ombyggnaden.

Byt endast ut en RAID-medlem åt gången

stäng av;
ersätt den första gamla disken med den större disken;
starta;
använd ZimaOS Recovery för att bygga om;
vänta tills återställningen är helt klar.

Upprepa för den andra medlemmen

Först efter att den första ombyggnaden var klar stängde användaren av systemet och bytte ut den andra disken, körde GUI-återställningen igen och väntade på att den skulle slutföras helt.

I det här skedet var arrayen frisk på två större fysiska enheter, men hade fortfarande storleken för de historiska medlemsenheterna.

Därefter utökade community-användaren mdadm-arrayen

Källkommandot var:

sudo mdadm --grow /dev/md0 --size=max

De verifierade den nya array-geometrin med mdadm --detail och väntade på att det nya återställnings-/omsynkroniseringstillståndet skulle slutföras.

Anta aldrig att din array är /dev/md0; identifiera den faktiska arrayen först.

Därefter måste Btrfs-filsystemet utökas

Källan avslutades med:

sudo btrfs filesystem resize max /your/mounted/filesystem

Använd den faktiska monterade Btrfs-sökvägen i stället för att kopiera platshållaren ordagrant.

Varför två storleksändringssteg krävdes

Linux md RAID-enheten;
Btrfs-filsystemet som ligger ovanpå det.

Båda måste exponera den större storleken innan användarna ser den extra kapaciteten.

Behandla detta som en versionsspecifik community-procedur

Källan anger uttryckligen att användaren körde ZimaOS+ 1.5.4. Den aktuella versionen av ZimaOS är nyare, och beteendet för lagringshanteringen kan ha ändrats. Innan du kör manuella mdadm --grow för produktionslagring ska du verifiera att gränssnittet fortfarande saknar en stödd utökningsväg och överväga att fråga IceWhale-supporten efter den aktuella proceduren.

Verifiera RAID-hälsan före varje fysiskt diskbyte

Innan du byter ut den första disken — och återigen innan du byter ut den andra — ska du bekräfta att arrayen är felfri och helt synkroniserad. Om du påbörjar det andra bytet innan den första ombyggnaden är klar försvinner den redundans du förlitar dig på under uppgraderingen.

Anteckna medlemsdiskarnas serienummer så att den fysiska disk du tar bort motsvarar den logiska medlem som visas av ZimaOS.

Ersättningsdiskar måste ha tillräcklig faktisk kapacitet

Diskar med nominellt lika stor kapacitet kan skilja sig något i antal användbara sektorer. Den säkraste utökningen använder ersättningsdiskar som är tydligt större än de gamla medlemmarna och minst lika stora som varandra.

Om den andra ”1 TB”-disken är marginellt mindre än den första kanske md-utöknings-/ombyggnadssteget inte fungerar som förväntat.

Räkna med mer än en återsynkroniseringscykel

Källans arbetsflöde byggde om arrayen efter det första fysiska bytet, byggde om den efter det andra och gick sedan in i ännu ett återställnings-/återsynkroniseringstillstånd efter mdadm --grow. Det innebär att en kapacitetsuppgradering kan ta betydligt längre tid än att bara byta ut två diskar.

Anslut NAS-enheten till en tillförlitlig strömkälla och undvik onödiga omstarter under varje återställningsfas.

Verifiera både blockenheten och filsystemet i slutet

Efter den slutliga Btrfs-ändringen av storleken ska resultatet verifieras från mer än ett lager:

mdadm --detail — md-RAID-geometri;
df -h eller Btrfs-filsystemverktyg — användbar filsystemskapacitet;
ZimaOS lagringsgränssnitt — förväntad poolstorlek och felfritt tillstånd.

Om något lager fortfarande visar den gamla storleken ska du stoppa och undersöka i stället för att blint upprepa utökningskommandon.

Vanliga frågor om utökning av RAID 1

Kan en större disk omedelbart öka RAID1-kapaciteten?

Nej. Speglingen begränsas fortfarande av den mindre medlemmen och arrayens historiska geometri.

Ökade kapaciteten automatiskt när båda de mindre diskarna ersattes i källan?

Nej. Användaren var fortfarande tvungen att utöka md-arrayen och sedan ändra storlek på Btrfs.

Var det manuella arbetsflödet för utökning bekräftat av källan?

Ja, av en användare av ZimaOS+ 1.5.4. Det publicerades inte som en officiell IceWhale-procedur.