De bron bewijst dat het vervangen van beide RAID 1-leden door grotere schijven het bruikbare bestandssysteem niet automatisch uitbreidt. Een gebruiker verving met succes twee schijven van 500 GB één voor één door schijven van 1 TB en liet ZimaOS na elke vervanging de array opnieuw opbouwen. Op dat moment waren beide fysieke leden 1 TB groot, maar de RAID/het apparaat en het Btrfs-bestandssysteem boden nog steeds slechts de oude capaciteit van 500 GB.
Op ZimaOS+ 1.5.4 voltooide die gebruiker de uitbreiding vervolgens via SSH met mdadm --grow /dev/md0 --size=max, wachtte op het daaropvolgende herstel/de resynchronisatie en voerde ten slotte uit btrfs filesystem resize max tegen het aangekoppelde bestandssysteem. Ze meldden dat de GUI en df en toonde vervolgens de grotere capaciteit. Dit is sterke bevestiging vanuit de community, maar het blijft een handmatige CLI-workflow en geen actuele IceWhale-GUI-procedure.
Maak een back-up voordat je de capaciteit gaat uitbreiden
RAID 1 beschermt tegen het uitvallen van één lid; het beschermt niet tegen bedieningsfouten, beschadigde arraymetagegevens, fouten in het bestandssysteem of problemen met een tweede schijf tijdens de reconstructie.
Vervang slechts één RAID-lid tegelijk
- schakel het systeem uit;
- vervang de eerste oude schijf door de grotere schijf;
- opstarten;
- gebruik ZimaOS Recovery om de array opnieuw op te bouwen;
- wacht tot het herstel volledig is voltooid.
Herhaal dit voor het tweede lid
Pas nadat de eerste reconstructie was voltooid, schakelde de gebruiker het systeem uit en verving die de tweede schijf. Daarna voerde de gebruiker het GUI-herstel opnieuw uit en wachtte tot dit volledig was voltooid.
In dit stadium was de array gezond op twee grotere fysieke schijven, maar had deze nog steeds de omvang van de historische leden.
De communitygebruiker vergrootte vervolgens de mdadm-array
De opdracht in de bron was:
sudo mdadm --grow /dev/md0 --size=maxZe controleerden de nieuwe arrayconfiguratie met mdadm --detail en wachtte tot de nieuwe herstel-/resynchronisatiestatus was voltooid.
Ga er nooit van uit dat je array /dev/md0; identificeer eerst de daadwerkelijke array.
Daarna moest het Btrfs-bestandssysteem worden uitgebreid
De bron eindigde met:
sudo btrfs filesystem resize max /your/mounted/filesystemGebruik het daadwerkelijk aangekoppelde Btrfs-pad in plaats van de plaatshouder letterlijk te kopiëren.
Waarom er twee stappen voor het vergroten nodig waren
- het Linux md RAID-apparaat;
- het Btrfs-bestandssysteem dat erop staat.
Beide moeten de grotere omvang beschikbaar maken voordat gebruikers de extra capaciteit zien.
Behandel dit als een communityprocedure die specifiek is voor deze versie
De gebruiker in de bron draaide expliciet ZimaOS+ 1.5.4. Het huidige ZimaOS is nieuwer en het gedrag van opslagbeheer kan zijn veranderd. Voordat je handmatige mdadm --grow controleer bij productieopslag of de interface nog steeds geen ondersteund uitbreidingspad biedt en overweeg IceWhale-support te vragen naar de actuele procedure.
Controleer de RAID-status vóór elke fysieke schijfwissel
Controleer vóór het vervangen van de eerste schijf — en opnieuw vóór het vervangen van de tweede — of de array gezond en volledig gesynchroniseerd is. Als je de tweede vervanging start voordat de eerste rebuild is voltooid, verlies je de redundantie waarop je tijdens de upgrade vertrouwt.
Noteer de serienummers van de leden, zodat de fysieke schijf die je verwijdert overeenkomt met het logische lid dat door ZimaOS wordt weergegeven.
Vervangende schijven hebben voldoende werkelijke capaciteit nodig
Schijven met nominaal dezelfde capaciteit kunnen enigszins verschillen in het aantal bruikbare sectoren. De veiligste uitbreiding gebruikt vervangende schijven die duidelijk groter zijn dan de oude leden en minstens even groot zijn als elkaar.
Als de tweede schijf van “1 TB” een fractie kleiner is dan de eerste, verloopt de md-grow-/rebuildstap mogelijk niet zoals verwacht.
Houd rekening met meer dan één resynchronisatiecyclus
De workflow uit de bron voerde na de eerste fysieke vervanging een rebuild uit, na de tweede opnieuw, en ging daarna nog een keer over naar een herstel-/resynchronisatiestatus nadat de mdadm --grow. Dat betekent dat een capaciteitsupgrade aanzienlijk langer kan duren dan het simpelweg verwisselen van twee schijven.
Houd de NAS tijdens elke herstelfase aangesloten op betrouwbare stroom en vermijd onnodige herstarts.
Controleer aan het einde zowel het blokapparaat als het bestandssysteem
Controleer het resultaat na het voltooien van de laatste Btrfs-aanpassing op meer dan één laag:
-
mdadm --detail— md RAID-geometrie; -
df -hof Btrfs-bestandssysteemtools — bruikbare bestandssysteemcapaciteit; - ZimaOS-opslaginterface — verwachte poolgrootte en gezonde status.
Als één laag nog steeds de oude grootte toont, stop dan en onderzoek dit in plaats van blindelings grow-opdrachten te herhalen.
Veelgestelde vragen over RAID 1-uitbreiding
Kan één grotere schijf de RAID1-capaciteit onmiddellijk vergroten?
Nee. De mirror blijft beperkt door het kleinere lid en de historische arraygeometrie.
Verhoogde het vervangen van beide kleinere schijven automatisch de capaciteit in de bron?
Nee. De gebruiker moest de md-array nog vergroten en daarna Btrfs aanpassen.
Was de handmatige workflow voor vergroten in de bron bevestigd?
Ja, door één ZimaOS+ 1.5.4-gebruiker. Het was niet als officiële IceWhale-procedure gepubliceerd.
