RAIDアレイが突然読み取り専用になった場合、すぐに読み書き可能な状態へ戻すことが最優先とは限りません。より重要なのは、なぜアレイが1台以上のディスクを信頼できなくなったのかを確認することです。
2026年5月のこのスレッドでは、4台構成のRAID 5が、メンバーディスクの一時的な消失後に保護用の読み取り専用状態へ移行しました。その後、アレイは正常な [UUUU] 状態に戻り、長時間にわたる保護・再同期処理を開始しましたが、ディスクの切断は再び発生しました。そこで議論は、「書き込みアクセスをどうやって復元するか」から、ハードウェアの通信経路の問題へと移りました。
アレイが保護用の読み取り専用モードに移行
スレッドには、ユーザーが誤って読み取り専用スイッチをクリックしたことを示す内容はありませんでした。コミュニティの分析では、この状態はストレージの劣化または不安定な状態への対応として発生したものと考えられていました。
RAIDが復旧しても、根本的な問題が残っている可能性がある
再起動と復旧の後、4台すべてのRAIDメンバーが再び認識され、アレイは「保護処理中」の状態になりました。
パリティの再同期中に何度も再起動すると、復旧処理が再開されたり、長引いたりする可能性があります。コミュニティは、ディスクが消失した原因を調査しながら、アレイの保護処理が完了するまで待つよう助言しました。
SMARTは合格でも、インターフェースのエラー履歴は重要
2台のToshiba製ディスクは、共有された出力上では総合的なSMARTヘルスが合格で、再割り当てセクタや保留中のセクタもありませんでした。そのため、「ディスクが確実に故障している」と単純に結論付ける根拠はありませんでした。
ただし、SMARTログにはUltra DMA CRCカウントと、複数のICRC/ABRTコマンドエラーも表示されていました。これらの項目は、メディアの欠陥だけでなく、ドライブとホスト間の通信障害に関連することが一般的です。そのためコミュニティは、SATAデータケーブル、電源供給、コントローラーの安定性、ファームウェア、繰り返し発生するリンクリセットに注目しました。
劣化したアレイを無理に読み書き可能な状態へ戻さない
このスレッドには、保護状態を安全に上書きするIceWhale作成のコマンドは掲載されていません。長期的な指針としては、それが適切な境界です。アクセス可能なデータをバックアップし、アレイの健全性を確認し、物理接続を点検し、保護を回避する前に切断の原因を診断してください。
現在のストレージパネルでアレイの健全性を確認する
現在のZimaOSでは、設定 > ストレージからストレージの健全性とメンバードライブの状態を確認できます。最新リリースでトラブルシューティングを行う場合は、この2026年の事例に基づく判断を適用する前に、現在のストレージインターフェースがアレイとメンバードライブをどのように表示するかを確認してください。
ZimaOSの読み取り専用RAIDに関するFAQ
ZimaOSが正常なRAIDをランダムに読み取り専用へ変更したのですか？
情報源からは、メンバードライブの切断が原因だったことが示されています。保護状態は、単独のUI設定変更ではなく、ディスクの欠落と同時に発生していました。
SMARTによってToshiba製ドライブの故障が証明されたのですか？
いいえ。総合的なSMARTヘルスは合格し、一般的なセクタ故障カウンターもゼロでした。ただし、ログには重大なインターフェース通信エラーが含まれていました。
CRCまたはICRCエラーが表示された場合、何を調査すべきですか？
コミュニティは、SATAケーブル、電源接続、電源ユニットの安定性、コントローラーの動作、ファームウェア、そして同じドライブまたはポートが繰り返し切断されていないかを調査しました。
IceWhaleによる公式の根本原因診断はありましたか？
いいえ。公開されたスレッドは、IceWhaleのエンジニアリング上の結論ではなく、コミュニティによるハードウェア分析で終わっています。
