Quando un array RAID diventa improvvisamente di sola lettura, forzarlo nuovamente in lettura-scrittura non è la prima priorità. La domanda più importante è perché l’array abbia perso fiducia in uno o più dischi.
In questa discussione di maggio 2026, un RAID 5 a quattro dischi è entrato in uno stato protettivo di sola lettura dopo che un disco membro è temporaneamente scomparso. In seguito, l’array è tornato allo stato integro [UUUU] e ha avviato una lunga procedura di protezione/risincronizzazione, ma le disconnessioni dei dischi si sono ripresentate. La discussione si è quindi spostata da «come riattivo l’accesso in scrittura?» al percorso di comunicazione hardware.
L’array è entrato in modalità protettiva di sola lettura
La discussione non mostrava che l’utente avesse attivato accidentalmente un interruttore di sola lettura. L’analisi della community ha interpretato lo stato come una risposta a una condizione di archiviazione degradata o instabile.
Il RAID poteva riprendersi e avere comunque un problema sottostante
Dopo il riavvio e il ripristino, tutti e quattro i membri RAID erano nuovamente visibili e l’array è entrato nello stato «Protezione in corso».
Riavviare ripetutamente il sistema durante una risincronizzazione della parità può riavviare o prolungare le attività di ripristino. Il consiglio della community era lasciare che l’array completasse la procedura di protezione, indagando nel frattempo sul motivo della scomparsa delle unità.
SMART superato, ma la cronologia degli errori dell’interfaccia era importante
I due dischi Toshiba riportavano uno stato generale SMART superato, senza settori riallocati o in sospeso nell’output condiviso. Questo non supportava una semplice conclusione secondo cui «i dischi sono sicuramente guasti».
Tuttavia, i registri SMART mostravano anche conteggi Ultra DMA CRC e diversi errori di comando ICRC/ABRT. Questi campi sono comunemente associati a problemi di comunicazione tra un’unità e l’host, più che a soli difetti del supporto. Perciò la community si è concentrata sui cavi dati SATA, sull’alimentazione, sulla stabilità del controller, sul firmware e sui ripetuti reset del collegamento.
Non forzare un array degradato nuovamente in lettura-scrittura
La discussione non contiene alcun comando ufficiale di IceWhale che sovrascriva in sicurezza lo stato protettivo. Per indicazioni applicabili nel tempo, questo è il limite corretto: eseguire il backup dei dati accessibili, verificare lo stato dell’array, controllare i collegamenti fisici e diagnosticare la disconnessione prima di tentare di aggirare la protezione.
Usa il pannello Archiviazione attuale per confermare lo stato dell’array
Le versioni attuali di ZimaOS mostrano lo stato dell’archiviazione e delle unità membro in Impostazioni > Archiviazione. Quando risolvi un problema in una versione moderna, controlla come l’interfaccia Archiviazione attuale segnala l’array e le relative unità membro prima di applicare le conclusioni di questo incidente del 2026.
Domande frequenti sul RAID di sola lettura in ZimaOS
ZimaOS ha trasformato casualmente in sola lettura un RAID integro?
Le prove disponibili indicano disconnessioni delle unità membro. Lo stato protettivo è comparso insieme a un disco mancante, non come modifica isolata di un’impostazione dell’interfaccia.
SMART ha dimostrato che i dischi Toshiba erano guasti?
No. Lo stato generale SMART era superato e i contatori comuni dei guasti dei settori erano pari a zero, sebbene i registri contenessero numerosi errori di comunicazione dell’interfaccia.
Cosa devo controllare quando compaiono errori CRC o ICRC?
La community si è concentrata sui cavi SATA, sui collegamenti di alimentazione, sulla stabilità dell’alimentatore, sul comportamento del controller, sul firmware e sulla verifica che la stessa unità o la stessa porta si disconnettano ripetutamente.
IceWhale ha fornito una diagnosi ufficiale della causa principale?
No. La discussione pubblicata si è conclusa con un’analisi hardware della community, senza una conclusione tecnica da parte di IceWhale.
