La procedura originale dimostra che la sostituzione di entrambi i membri RAID 1 con dischi più grandi **non espande automaticamente il filesystem utilizzabile**. Un utente ha sostituito con successo due dischi da 500 GB con due dischi da 1 TB, uno alla volta, consentendo a ZimaOS di ricostruire l’array dopo ogni sostituzione. A quel punto entrambi i membri fisici erano da 1 TB, ma il RAID/dispositivo e il filesystem Btrfs esponevano ancora solo la vecchia capacità di 500 GB.
Su ZimaOS+ 1.5.4, l’utente ha quindi completato l’espansione tramite SSH con mdadm --grow /dev/md0 --size=max, hanno atteso il ripristino/risincronizzazione risultante e infine hanno eseguito btrfs filesystem resize max sul filesystem montato. Hanno riferito che la GUI e df poi ha mostrato la capacità maggiore. Questa è una forte verifica da parte della community, ma si tratta comunque di una procedura manuale da CLI, non di una procedura attuale dalla GUI di IceWhale.
Esegui un backup prima di iniziare l’espansione della capacità
RAID 1 protegge dal guasto di un membro; non protegge da errori dell’operatore, danni ai metadati dell’array, errori del filesystem o problemi al secondo disco durante la ricostruzione.
Sostituisci un solo membro RAID alla volta
- spegni il sistema;
- sostituisci il primo vecchio disco con quello più grande;
- avvia;
- usa ZimaOS Recovery per ricostruirlo;
- attendi il completamento del ripristino.
Ripeti per il secondo membro
Solo dopo il completamento della prima ricostruzione l’utente ha spento il sistema e sostituito il secondo disco, quindi ha eseguito nuovamente il ripristino dalla GUI e atteso il completamento.
A questo punto l’array era integro su due dispositivi fisici più grandi, ma aveva ancora le dimensioni storiche dei membri.
L’utente della community ha quindi espanso l’array mdadm
Il comando originale era:
sudo mdadm --grow /dev/md0 --size=maxHanno verificato la nuova geometria dell’array con mdadm --detail e ha atteso il completamento del nuovo stato di ripristino/risincronizzazione.
Non dare mai per scontato che il tuo array sia /dev/md0; identifica prima l’array effettivo.
Poi è stato necessario espandere il filesystem Btrfs
La procedura originale si è conclusa con:
sudo btrfs filesystem resize max /your/mounted/filesystemUsa il percorso Btrfs effettivamente montato invece di copiare letteralmente il segnaposto.
Perché erano necessari due passaggi di ridimensionamento
- il dispositivo RAID md di Linux;
- il filesystem Btrfs che vi risiede.
Entrambi devono esporre la capacità maggiore prima che gli utenti possano vedere lo spazio aggiuntivo.
Considerala una procedura della community specifica per la versione
La fonte indica esplicitamente che l'utente eseguiva ZimaOS+ 1.5.4. La versione attuale di ZimaOS è più recente e il comportamento della gestione dell'archiviazione può cambiare. Prima di eseguire comandi manuali mdadm --grow nell'archiviazione di produzione, verifica che l'interfaccia non offra ancora un percorso di espansione supportato e valuta la possibilità di chiedere all'assistenza IceWhale la procedura aggiornata.
Verifica lo stato RAID prima di ogni sostituzione fisica
Prima di sostituire il primo disco e di nuovo prima di sostituire il secondo, verifica che l'array sia integro e completamente sincronizzato. Avviare la seconda sostituzione mentre la prima ricostruzione è incompleta elimina la ridondanza su cui fai affidamento durante l'aggiornamento.
Annota i numeri di serie dei membri, in modo che il disco fisico rimosso corrisponda al membro logico mostrato da ZimaOS.
I dischi sostitutivi devono avere una capacità reale sufficiente
Dischi con capacità nominale uguale possono differire leggermente nel numero di settori utilizzabili. L'espansione più sicura usa dischi sostitutivi chiaramente più grandi dei vecchi membri e grandi almeno quanto gli altri.
Se il secondo disco da “1 TB” è leggermente più piccolo del primo, il passaggio di espansione/ricostruzione md potrebbe non comportarsi come previsto.
Prevedi più di un ciclo di risincronizzazione
Il flusso della fonte ha ricostruito l'array dopo la prima sostituzione fisica, lo ha ricostruito dopo la seconda e poi è entrato in un altro stato di ripristino/risincronizzazione dopo il mdadm --grow. Ciò significa che un aggiornamento della capacità può richiedere molto più tempo della semplice sostituzione di due dischi.
Mantieni il NAS collegato a un'alimentazione affidabile ed evita riavvii non necessari durante ogni fase del ripristino.
Verifica il dispositivo a blocchi e il filesystem alla fine
Dopo il ridimensionamento finale di Btrfs, verifica il risultato su più di un livello:
-
mdadm --detail— geometria RAID md; -
df -hoppure gli strumenti del filesystem Btrfs — capacità utilizzabile del filesystem; - Interfaccia di archiviazione di ZimaOS — dimensione prevista del pool e stato integro.
Se un livello mostra ancora le dimensioni precedenti, interrompi la procedura e verifica invece di ripetere ciecamente i comandi di espansione.
FAQ sull'espansione RAID 1
Un disco più grande può aumentare immediatamente la capacità RAID1?
No. Il mirror rimane vincolato al membro più piccolo e alla geometria storica dell'array.
La sostituzione di entrambi i dischi più piccoli aumentava automaticamente la capacità nella fonte?
No. L'utente doveva comunque espandere l'array md e poi ridimensionare Btrfs.
Il flusso manuale di espansione era stato confermato dalla fonte?
Sì, da parte di un utente di ZimaOS+ 1.5.4. Non è stata pubblicata come procedura ufficiale di IceWhale.
