Wenn ein RAID-Array plötzlich schreibgeschützt wird, hat es keine höchste Priorität, es sofort wieder auf Lesen und Schreiben umzustellen. Die wichtigere Frage ist, warum das Array das Vertrauen in eine oder mehrere Festplatten verloren hat.
In diesem Thread vom Mai 2026 wechselte ein RAID 5 mit vier Festplatten in einen schützenden schreibgeschützten Zustand, nachdem eine Mitgliedsfestplatte vorübergehend verschwunden war. Später kehrte das Array in einen gesunden Zustand [UUUU] zurück und begann mit einem langen Schutz-/Resynchronisierungsvorgang, doch die Laufwerksausfälle traten erneut auf. Daraufhin verlagerte sich die Diskussion von „Wie aktiviere ich den Schreibzugriff wieder?“ auf den Kommunikationspfad der Hardware.
Das Array wechselte in den schützenden schreibgeschützten Modus
Der Thread zeigte nicht, dass der Benutzer versehentlich einen Schalter für den schreibgeschützten Modus betätigt hatte. Die Community-Analyse wertete den Zustand als Reaktion auf eine beeinträchtigte oder instabile Speicherumgebung.
Das RAID konnte sich erholen und trotzdem ein grundlegendes Problem haben
Nach dem Neustart und der Wiederherstellung waren alle vier RAID-Mitglieder wieder sichtbar, und das Array wechselte in den Zustand „Schutz wird ausgeführt“.
Wiederholte Neustarts während einer Paritätsresynchronisierung können die Wiederherstellungsarbeiten neu starten oder verlängern. Die Community empfahl, den Schutzvorgang des Arrays vollständig abzuschließen und gleichzeitig zu untersuchen, warum die Laufwerke verschwunden waren.
SMART war erfolgreich, aber der Fehlerverlauf der Schnittstelle war relevant
Die beiden Toshiba-Festplatten meldeten im bereitgestellten Bericht insgesamt einen erfolgreichen SMART-Zustand, ohne neu zugewiesene oder ausstehende Sektoren. Daher war die einfache Schlussfolgerung „Die Festplatten sind definitiv defekt“ nicht gerechtfertigt.
Die SMART-Protokolle zeigten jedoch auch Ultra-DMA-CRC-Zähler sowie mehrere ICRC-/ABRT-Befehlsfehler. Diese Felder stehen häufig mit einer fehlerhaften Kommunikation zwischen Laufwerk und Host in Verbindung und nicht ausschließlich mit Medienfehlern. Deshalb konzentrierte sich die Community auf SATA-Datenkabel, die Stromversorgung, die Stabilität des Controllers, die Firmware und wiederholte Zurücksetzungen der Verbindung.
Ein degradiertes Array nicht gewaltsam wieder auf Lesen und Schreiben umstellen
Der Thread enthält keinen von IceWhale verfassten Befehl, der den schützenden Zustand sicher außer Kraft setzt. Für langfristig gültige Empfehlungen ist dies die richtige Grenze: Sichern Sie zugängliche Daten, überprüfen Sie den Zustand des Arrays, kontrollieren Sie die physischen Verbindungen und diagnostizieren Sie den Ausfall, bevor Sie versuchen, den Schutz zu umgehen.
Mit dem aktuellen Speicherbereich den Zustand des Arrays überprüfen
Das aktuelle ZimaOS zeigt den Zustand des Speichers und den Status der Mitgliedslaufwerke unter Einstellungen > Speicher an. Wenn Sie eine moderne Version untersuchen, prüfen Sie, wie die aktuelle Speicheroberfläche das Array und seine Mitgliedslaufwerke meldet, bevor Sie aus diesem Vorfall von 2026 Schlussfolgerungen ableiten.
FAQ zu schreibgeschützten ZimaOS-RAIDs
Hat ZimaOS ein gesundes RAID zufällig auf schreibgeschützt umgestellt?
Die verfügbaren Belege deuten auf Ausfälle von Mitgliedslaufwerken hin. Der schützende Zustand trat zusammen mit einer fehlenden Festplatte auf und nicht als isolierte Änderung einer Einstellung in der Benutzeroberfläche.
Hat SMART bewiesen, dass die Toshiba-Festplatten ausgefallen waren?
Nein. Der allgemeine SMART-Zustand war erfolgreich, und die gängigen Zähler für Sektorausfälle standen auf null, obwohl die Protokolle erhebliche Kommunikationsfehler der Schnittstelle enthielten.
Was sollte ich untersuchen, wenn CRC- oder ICRC-Fehler auftreten?
Die Community konzentrierte sich auf SATA-Kabel, Stromverbindungen, die Stabilität des Netzteils, das Verhalten des Controllers, die Firmware und darauf, ob immer wieder dasselbe Laufwerk oder derselbe Anschluss ausfällt.
Gab es eine offizielle Ursachenanalyse von IceWhale?
Nein. Der veröffentlichte Thread endete mit einer Hardware-Analyse der Community und nicht mit einer technischen Schlussfolgerung von IceWhale.
