Wanneer een RAID-array plotseling alleen-lezen wordt, is het niet de eerste prioriteit om deze weer naar lezen-en-schrijven te forceren. De belangrijkere vraag is waarom de array het vertrouwen in een of meer schijven verloor.
In deze thread uit mei 2026 kwam een RAID 5 met vier schijven na het tijdelijk verdwijnen van een schijf in een beschermde alleen-lezenstatus terecht. De array keerde later terug naar een gezonde [UUUU]-status en begon aan een lange beschermings-/resynchronisatiepassage, maar de schijfuitval trad opnieuw op. De discussie verschoof daardoor van ‘hoe krijg ik schrijftoegang terug?’ naar het hardwarecommunicatiepad.
De array kwam in de beschermde alleen-lezenmodus terecht
Uit de thread bleek niet dat de gebruiker per ongeluk een alleen-lezenoptie had ingeschakeld. De community-analyse beschouwde deze status als een reactie op een gedegradeerde of instabiele opslagtoestand.
De RAID kon herstellen en toch een onderliggend probleem hebben
Na het opnieuw opstarten en herstellen waren alle vier RAID-leden weer zichtbaar en kwam de array in de status ‘Beveiliging wordt uitgevoerd’.
Herhaaldelijk opnieuw opstarten tijdens een pariteitsresynchronisatie kan het herstelwerk opnieuw starten of verlengen. Het advies van de community was om de array de beschermingspassage te laten voltooien en tegelijkertijd te onderzoeken waarom de schijven verdwenen.
SMART slaagde, maar de foutgeschiedenis van de interface was wel belangrijk
De twee Toshiba-schijven rapporteerden in de gedeelde uitvoer dat de algemene SMART-status geslaagd was, zonder opnieuw toegewezen of in behandeling zijnde sectoren. Daardoor was een eenvoudige conclusie als ‘de schijven zijn zeker defect’ niet onderbouwd.
De SMART-logboeken toonden echter ook Ultra DMA CRC-tellingen en meerdere ICRC/ABRT-opdrachtfouten. Deze velden worden doorgaans geassocieerd met mislukte communicatie tussen een schijf en de host, en niet uitsluitend met defecten aan het opslagmedium. Daarom richtte de community zich op SATA-datakabels, stroomvoorziening, controllerstabiliteit, firmware en herhaalde linkresets.
Forceer een gedegradeerde array niet terug naar lezen-en-schrijven
De thread bevat geen door IceWhale geschreven opdracht waarmee de beschermde status veilig kan worden overschreven. Voor langdurige richtlijnen is dat de juiste grens: maak een back-up van toegankelijke gegevens, controleer de gezondheid van de array, inspecteer de fysieke verbindingen en stel vast waardoor de uitval ontstaat voordat je probeert de bescherming te omzeilen.
Gebruik het huidige opslagpaneel om de gezondheid van de array te controleren
Het huidige ZimaOS toont de opslagstatus en de status van de afzonderlijke schijven onder Instellingen > Opslag. Wanneer je een moderne release onderzoekt, controleer dan hoe de huidige opslaginterface de array en de afzonderlijke schijven rapporteert voordat je conclusies uit dit incident uit 2026 toepast.
Veelgestelde vragen over alleen-lezen-RAID in ZimaOS
Heeft ZimaOS een gezonde RAID willekeurig gewijzigd in alleen-lezen?
Het bronmateriaal wijst op het uitvallen van RAID-schijven. De beschermde status verscheen samen met een ontbrekende schijf, en niet als een op zichzelf staande wijziging van een interface-instelling.
Bewees SMART dat de Toshiba-schijven defect waren?
Nee. De algemene SMART-status was geslaagd en veelgebruikte tellers voor sectorfouten stonden op nul, hoewel de logboeken aanzienlijke communicatiefouten van de interface bevatten.
Wat moet ik onderzoeken wanneer CRC- of ICRC-fouten verschijnen?
De community richtte zich op SATA-kabels, stroomaansluitingen, stabiliteit van de voeding, controllergedrag, firmware en de vraag of steeds dezelfde schijf of poort uitvalt.
Was er een officiële diagnose van de hoofdoorzaak door IceWhale?
Nee. De gepubliceerde thread eindigde met een hardwareanalyse van de community en niet met een technische conclusie van IceWhale.
