Risoluzione dei problemi RAID di ZimaOS su hardware non ZimaCube

Se ZimaOS rileva le tue unità ma la schermata di creazione RAID le assegna agli alloggiamenti sbagliati, lascia vuoti gli slot selezionabili o mostra solo alcuni dischi, separa innanzitutto un problema attuale di integrità RAID dal vecchio problema di associazione dei dischi su hardware non ZimaCube documentato in questa discussione. La pagina 2 riflette in gran parte il comportamento di ZimaOS 1.2.x e delle prime versioni 1.3.x sull'hardware fai-da-te.

L'attuale risoluzione dei problemi RAID di ZimaOS inizia dal numero di unità, dallo stato dei dischi, dalla formattazione individuale, da un punto di montaggio vuoto e da un riavvio. Solo dopo questi controlli dovresti valutare le vecchie soluzioni alternative per l'associazione degli alloggiamenti, e solo se riesci a riprodurre lo stesso difetto di associazione nella versione attuale.

Come appariva il vecchio bug di associazione dei dischi

Diversi utenti con hardware non ZimaCube hanno riferito che le unità collegate fisicamente apparivano in posizioni virtuali impreviste. La pagina dello spazio di archiviazione poteva mostrare i dischi negli alloggiamenti 4, 5 e 6, mentre la finestra RAID si aspettava i dischi nelle posizioni iniziali, lasciando il pulsante Avanti non disponibile o nascondendo un'unità dalla selezione.

Vecchia vista dello spazio di archiviazione di ZimaOS con dischi non ZimaCube assegnati a alloggiamenti imprevisti — Una versione precedente di ZimaOS associava i dischi dell'hardware fai-da-te a posizioni degli alloggiamenti impreviste.

Vecchio Gestore archiviazione di ZimaOS con dischi visualizzati negli alloggiamenti 4, 5 e 6 — L'interfaccia di archiviazione poteva riconoscere i dischi, mentre il modello di selezione RAID continuava a renderne difficile l'utilizzo.

Riconoscimento e idoneità al RAID erano due livelli diversi

Vecchia schermata di creazione RAID di ZimaOS su hardware LincStation con alloggiamenti dei dischi non disponibili — Un sistema fai-da-te poteva elencare lo spazio di archiviazione, ma lasciare comunque incompleto il flusso di selezione RAID.

Questa distinzione è ancora utile oggi. Vedere un disco in lsblk dimostra che il kernel rileva un dispositivo a blocchi. Visualizzarlo in File o nel Gestore archiviazione dimostra che un altro livello lo riconosce. Poterlo selezionare per il RAID aggiunge un ulteriore livello di idoneità e interfaccia.

Se un livello non funziona, individua il punto in cui il disco scompare invece di cancellarlo immediatamente. Controlla lo stato del file system, i metadati RAID esistenti, lo stato del montaggio e se l'interfaccia attuale considera il disco disponibile per un nuovo array.

Vecchio pannello «Nuovo disco rigido» di ZimaOS tratto da un caso di risoluzione dei problemi RAID su hardware non ZimaCube — Il livello di archiviazione poteva rilevare un'unità anche quando il flusso di lavoro RAID non la associava come previsto.

Vecchia schermata RAID0 di ZimaOS con un solo alloggiamento selezionabile su hardware fai-da-te — Un'altra schermata mostra la stessa discrepanza dal lato della creazione RAID: lo spazio di archiviazione rilevato non corrispondeva agli alloggiamenti selezionabili previsti.

Esegui i controlli RAID attuali prima di modificare la configurazione del sistema

L'attuale guida ufficiale alla risoluzione dei problemi RAID consiglia di verificare la presenza di almeno due unità, controllare lo stato dei dischi, confermare che ogni disco possa essere formattato correttamente, assicurarsi che il punto di montaggio RAID previsto sia vuoto e riavviare prima di ritentare la creazione.

Attuale checklist per la risoluzione dei problemi RAID in ZimaOS dovrebbe essere il tuo primo riferimento anche sull'hardware fai-da-te, perché evita supposizioni potenzialmente distruttive.

SataStartNumber era una soluzione alternativa della community specifica per una determinata versione

Nella vecchia discussione, una risposta del team IceWhale riconosceva che la logica dell'interfaccia delle prime versioni di ZimaOS era fortemente legata alla disposizione degli slot di ZimaCube. Agli utenti veniva indicato di esaminare la posizione dei dischi nel controller con lsblk -o hctl e, per determinati sistemi fai-da-te, modificare SataStartNumber in /etc/casaos/local-storage.conf.

Alcuni utenti hanno confermato che questa operazione correggeva la mappatura dei vani virtuali; in seguito, altri hanno riferito che versioni più recenti di ZimaOS risolvevano il problema nella loro configurazione senza mantenere la stessa soluzione alternativa. Ciò rende la modifica una tecnica storica di compatibilità, non un requisito universale attuale.

Non applicare una vecchia SataStartNumber valore proveniente da un'altra scheda madre. La topologia del controller varia a seconda del sistema e ZimaOS attuale potrebbe non utilizzare più le stesse ipotesi.

Le schermate mostrano perché è importante tenere conto dei limiti delle versioni

Gestione archiviazione di una versione precedente di ZimaOS dopo la correzione della mappatura dei vani dei dischi — In seguito, un utente ha mostrato i dischi nelle posizioni dei vani iniziali previste dopo aver risolto il problema di mappatura.

Schermata della versione di ZimaOS che mostra una build beta iniziale 1.3.1 — Parti della discussione sono state testate su build iniziali della serie 1.3.x, molto più vecchie dell'interfaccia attuale della serie 1.7.x.

ZimaOS 1.7.1 include anche una correzione per la visualizzazione inaccurata dello stato RAID in determinati scenari. Ciò non dimostra che ogni caso di mappatura dei vani fai-da-te sia stato risolto, ma è un ulteriore motivo per riprodurre il problema su una build attuale prima di seguire una modifica di configurazione del 2024.

Non trasformare la soluzione alternativa da shell per cinque dischi in una procedura generale

Un partecipante successivo disponeva di cinque dispositivi NVMe da 8 TB. L'interfaccia ne esponeva solo quattro per la creazione del RAID, sebbene il quinto dispositivo fosse visibile altrove, e l'utente alla fine ha espanso manualmente RAID5 con mdadm.

Vista dello spazio di archiviazione di una versione precedente di ZimaOS, con cinque dispositivi NVMe rilevati, uno dei quali assegnato a un numero di slot insolito — Il quinto NVMe era visibile al sistema, ma mappato in modo diverso rispetto ai primi quattro.

Elenco dei dischi di una versione precedente di ZimaOS, con cinque dispositivi membri di Linux RAID — L'elenco dei dischi e l'interfaccia di creazione del RAID non esponevano lo stesso insieme utilizzabile.

Schermata precedente di selezione di RAID5 in ZimaOS dal caso di risoluzione dei problemi con cinque unità NVMe — Il flusso di RAID5 faceva parte degli elementi usati per confrontare quali dischi fossero visibili e quali selezionabili.

Schermata precedente di creazione di RAID5 in ZimaOS, con solo quattro unità NVMe selezionabili — Il quinto dispositivo era assente dal normale passaggio di selezione di RAID5.

Stato di RAID5 in una versione precedente di ZimaOS mentre veniva integrato un quinto disco — L'utente alla fine ha espanso l'array dalla shell, ma tale procedura non viene riprodotta qui come raccomandazione generale.

Arrestare, riassemblare o espandere un array con comandi di basso livello può causare la perdita di dati se l'elenco dei dispositivi o le ipotesi sui metadati sono errati. Per un sistema attuale che riconosce i dischi ma non consente di usarli nell'interfaccia RAID, esegui il backup dei dati importanti e inoltra il problema indicando la versione, lsblk output, topologia del controller, schermate e stato dell'array esistente, anziché copiare la vecchia sequenza di comandi shell.