RAID 어레이가 갑자기 읽기 전용이 되었을 때, 이를 다시 읽기-쓰기로 강제 전환하는 것이 최우선은 아닙니다. 더 중요한 질문은 어레이가 하나 이상의 디스크를 신뢰할 수 없게 된 이유입니다.
2026년 5월의 이 스레드에서는 4개 디스크로 구성된 RAID 5가 구성원 디스크 하나가 일시적으로 사라진 후 보호용 읽기 전용 상태에 들어갔습니다. 이후 어레이는 정상적인 [UUUU] 상태로 돌아왔고 긴 보호/재동기화 작업을 시작했지만, 디스크 연결 끊김이 다시 발생했습니다. 이에 따라 논의의 초점은 “쓰기 액세스를 어떻게 다시 활성화하나요?”에서 하드웨어 통신 경로로 옮겨갔습니다.
어레이가 보호용 읽기 전용 모드로 전환됨
이 스레드에서는 사용자가 실수로 읽기 전용 스위치를 클릭했다는 내용이 나타나지 않았습니다. 커뮤니티의 분석에서는 이 상태를 성능이 저하되었거나 불안정한 저장소 상태에 대한 대응으로 보았습니다.
RAID가 복구되었더라도 근본적인 문제는 남아 있을 수 있음
재부팅과 복구 후에는 RAID 구성원 4개가 모두 다시 표시되었고, 어레이는 “보호 진행 중” 상태에 들어갔습니다.
패리티 재동기화 중에 반복적으로 재부팅하면 복구 작업이 다시 시작되거나 길어질 수 있습니다. 커뮤니티에서는 디스크가 사라진 원인을 조사하는 동안 어레이가 보호 작업을 완료하도록 두라고 조언했습니다.
SMART는 통과했지만 인터페이스 오류 기록이 중요함
두 Toshiba 디스크는 전체 SMART 상태가 통과로 표시되었고, 공유된 출력에는 재할당 섹터나 보류 중인 섹터가 없었습니다. 따라서 단순히 “디스크가 확실히 고장 났다”고 결론 내릴 근거는 부족했습니다.
그러나 SMART 로그에는 Ultra DMA CRC 카운트와 여러 ICRC/ABRT 명령 오류도 표시되었습니다. 이러한 항목은 미디어 결함만으로 발생하기보다는 드라이브와 호스트 간 통신 실패와 관련된 경우가 많습니다. 따라서 커뮤니티에서는 SATA 데이터 케이블, 전원 공급, 컨트롤러 안정성, 펌웨어, 반복적인 링크 재설정에 초점을 맞췄습니다.
성능이 저하된 어레이를 읽기-쓰기로 강제 전환하지 마세요
이 스레드에는 보호 상태를 안전하게 무시할 수 있는 IceWhale 공식 명령이 포함되어 있지 않습니다. 장기적으로 적용할 수 있는 지침의 기준은 다음과 같습니다. 액세스 가능한 데이터를 백업하고, 어레이 상태를 확인하며, 물리적 연결을 점검하고, 보호 기능을 우회하기 전에 연결 끊김의 원인을 진단하세요.
현재 저장소 패널에서 어레이 상태 확인
현재 ZimaOS에서는 설정 > 저장소에서 저장소 상태와 구성원 드라이브 상태를 확인할 수 있습니다. 최신 버전에서 문제를 해결할 때는 이 2026년 사례의 결론을 적용하기 전에 현재 저장소 인터페이스에서 어레이와 구성원 드라이브의 상태를 어떻게 표시하는지 확인하세요.
ZimaOS 읽기 전용 RAID FAQ
ZimaOS가 정상적인 RAID를 무작위로 읽기 전용으로 변경했나요?
원본 자료에서는 구성원 드라이브 연결 끊김을 원인으로 지목하고 있습니다. 보호 상태는 독립적인 UI 설정 변경이 아니라 디스크 하나가 사라진 상황과 함께 나타났습니다.
SMART가 Toshiba 드라이브의 고장을 입증했나요?
아니요. 전체 SMART 상태는 통과했고 일반적인 섹터 고장 카운터도 0이었지만, 로그에는 상당한 인터페이스 통신 오류가 포함되어 있었습니다.
CRC 또는 ICRC 오류가 나타나면 무엇을 조사해야 하나요?
커뮤니티에서는 SATA 케이블, 전원 연결, PSU 안정성, 컨트롤러 동작, 펌웨어, 그리고 동일한 드라이브나 포트에서 반복적으로 연결이 끊기는지 여부를 중점적으로 조사했습니다.
IceWhale의 공식 근본 원인 진단이 있었나요?
아니요. 공개된 스레드는 IceWhale 엔지니어링 팀의 결론 없이 커뮤니티의 하드웨어 분석으로 마무리되었습니다.
