비(非) ZimaCube 하드웨어에서 ZimaOS RAID 문제 해결

ZimaOS에서 드라이브를 인식하지만 RAID 생성 화면에서 드라이브를 잘못된 베이에 할당하거나, 선택 가능한 슬롯을 빈칸으로 남겨 두거나, 일부 디스크만 표시한다면 먼저 현재 RAID 상태 문제와 이 글에서 설명한 이전 ZimaCube 외 하드웨어의 디스크 매핑 문제를 구분하세요. 2페이지는 대체로 DIY 하드웨어에서의 ZimaOS 1.2.x 및 초기 1.3.x 동작을 반영합니다.

현재 ZimaOS RAID 문제 해결은 드라이브 수, 디스크 상태, 개별 포맷, 비어 있는 마운트 지점, 재부팅부터 시작합니다. 이러한 점검을 완료한 후에만 이전 슬롯 매핑 우회 방법을 고려해야 하며, 현재 버전에서도 동일한 매핑 결함을 재현할 수 있을 때만 사용해야 합니다.

이전 디스크 매핑 버그의 모습

ZimaCube가 아닌 하드웨어를 사용하는 여러 사용자는 물리적으로 연결된 드라이브가 예상하지 못한 가상 위치에 표시된다고 보고했습니다. 스토리지 페이지에는 베이 4, 5, 6에 디스크가 표시될 수 있었지만 RAID 대화 상자에서는 더 앞선 위치의 디스크를 요구하여 다음 버튼을 사용할 수 없거나 디스크 하나가 선택 목록에서 숨겨졌습니다.

ZimaCube가 아닌 디스크가 예상하지 못한 베이에 할당된 모습을 보여 주는 이전 ZimaOS 스토리지 화면 — 이전 ZimaOS 빌드에서는 DIY 하드웨어의 디스크가 예상하지 못한 베이 위치로 매핑되었습니다.

베이 4, 5, 6에 디스크가 표시된 이전 ZimaOS 스토리지 관리자 — 스토리지 인터페이스에서는 디스크를 인식하더라도 RAID 선택 모델에서는 디스크를 사용하기 어렵게 표시할 수 있었습니다.

인식과 RAID 사용 가능 여부는 서로 다른 두 계층이었습니다

사용할 수 없는 디스크 슬롯이 표시된 LincStation 하드웨어의 이전 ZimaOS RAID 생성 화면 — DIY 시스템에서 스토리지를 나열하더라도 RAID 선택 워크플로가 완성되지 않은 상태로 남을 수 있습니다.

이 구분은 오늘날에도 유용합니다. 디스크가 lsblk 커널이 블록 장치를 인식한다는 것을 의미합니다. 파일 또는 스토리지 관리자에 표시된다는 것은 또 다른 계층에서 인식한다는 것을 의미합니다. RAID에 선택 가능하다는 것은 추가적인 적격성 및 UI 계층이 있다는 뜻입니다.

한 계층에서 문제가 발생하면 즉시 디스크를 초기화하지 말고 디스크가 사라지는 지점을 기록하세요. 파일 시스템 상태, 기존 RAID 메타데이터, 마운트 상태, 현재 인터페이스에서 해당 디스크를 새 어레이에 사용할 수 있는 것으로 인식하는지를 확인해야 합니다.

ZimaCube가 아닌 RAID 문제 해결 사례에서 확인된 이전 ZimaOS의 새 하드 드라이브 패널 — RAID 워크플로에서 드라이브를 예상대로 매핑하지 못하더라도 스토리지 계층에서는 드라이브를 감지할 수 있었습니다.

DIY 하드웨어에서 디스크 베이 하나만 선택할 수 있었던 이전 ZimaOS RAID0 화면 — 또 다른 스크린샷은 RAID 생성 측면에서 동일한 불일치를 보여 줍니다. 감지된 스토리지가 예상한 선택 가능한 베이로 매핑되지 않았습니다.

시스템 구성을 수정하기 전에 현재 RAID 점검을 실행하세요

현재 공식 RAID 문제 해결 가이드에서는 최소 두 개의 드라이브가 인식되는지 확인하고, 디스크 상태를 점검하며, 각 디스크를 성공적으로 포맷할 수 있는지 확인하고, RAID 마운트 지점이 비어 있는지 점검한 후, 생성을 다시 시도하기 전에 재부팅할 것을 권장합니다.

현재 ZimaOS RAID 문제 해결 체크리스트를 DIY 하드웨어에서도 가장 먼저 확인해야 합니다. 파괴적인 가정을 피할 수 있기 때문입니다.

SataStartNumber는 버전별 커뮤니티 우회 방법이었습니다.

이전 스레드에서 IceWhale 팀의 답변은 초기 ZimaOS UI 로직이 ZimaCube 슬롯 배치와 강하게 연동되어 있었다고 인정했습니다. 사용자들은 다음 명령으로 디스크 컨트롤러 배치를 확인하라는 안내를 받았습니다. lsblk -o hctl 그리고 특정 DIY 시스템에서는 다음과 같이 조정합니다. SataStartNumber 에서 /etc/casaos/local-storage.conf.

일부 사용자는 이 방법으로 가상 베이 매핑이 수정되었다고 확인했지만, 이후 다른 사용자들은 동일한 우회 방법을 유지하지 않아도 최신 ZimaOS 릴리스에서 설정이 해결되었다고 보고했습니다. 따라서 이 편집 방법은 과거의 호환성 기법일 뿐, 현재 모든 경우에 필요한 보편적인 요구 사항은 아닙니다.

오래된 설정을 적용하지 마세요 SataStartNumber 다른 마더보드에서 가져온 값입니다. 시스템마다 컨트롤러 토폴로지가 다르며, 현재 ZimaOS는 더 이상 동일한 가정을 사용하지 않을 수 있습니다.

스크린샷은 버전 차이가 중요한 이유를 보여 줍니다

디스크 베이 매핑이 수정된 후의 이전 ZimaOS Storage Manager — 이후 한 사용자는 매핑 문제를 해결한 뒤 디스크가 예상된 초기 베이 위치에 표시되는 모습을 보여 주었습니다.

초기 1.3.1 베타 빌드를 표시하는 이전 ZimaOS 버전 화면 — 스레드의 일부 내용은 현재 1.7.x 인터페이스보다 훨씬 오래된 초기 1.3.x 빌드에서 테스트되었습니다.

ZimaOS 1.7.1에는 특정 상황에서 부정확하게 표시되는 RAID 상태를 수정하는 기능도 포함되어 있습니다. 이것이 모든 DIY 베이 매핑 문제가 해결되었다는 의미는 아니지만, 2024년 구성 편집을 따르기 전에 최신 빌드에서 문제를 재현해 볼 또 다른 이유가 됩니다.

다섯 디스크 셸 우회 방법을 일반적인 절차로 만들지 마세요

이후 한 사용자는 8TB NVMe 장치 다섯 개를 사용했습니다. 다섯 번째 장치가 다른 곳에서는 표시되었음에도 UI에서는 RAID 생성용으로 네 개만 표시되었고, 사용자는 결국 다음 명령으로 RAID5를 수동 확장했습니다. mdadm.

다섯 개의 NVMe 장치를 감지하고 그중 하나에 비정상적인 슬롯 번호를 할당한 이전 ZimaOS 스토리지 화면 — 다섯 번째 NVMe는 시스템에 표시되었지만 처음 네 개와는 다르게 매핑되었습니다.

다섯 개의 Linux RAID 멤버 장치를 표시하는 이전 ZimaOS 디스크 목록 — 디스크 목록과 RAID 생성 인터페이스에는 동일한 사용 가능한 디스크 세트가 표시되지 않았습니다.

다섯 개의 NVMe를 사용한 문제 해결 사례의 이전 ZimaOS RAID5 선택 화면 — RAID5 작업 흐름은 어떤 디스크가 표시되고 어떤 디스크를 선택할 수 있는지 비교하는 데 사용된 증거의 일부였습니다.

선택 가능한 NVMe 드라이브가 네 개만 표시된 이전 ZimaOS RAID5 생성 화면 — 일반적인 RAID5 선택 단계에서 다섯 번째 장치가 표시되지 않았습니다.

다섯 번째 디스크가 추가되는 동안의 이전 ZimaOS RAID5 상태 — 사용자는 결국 셸에서 어레이를 확장했지만, 해당 절차는 일반적인 권장 방법으로 여기서 재현하지 않습니다.

저수준 명령으로 어레이를 중지하거나 재조립하거나 확장할 경우, 장치 목록이나 메타데이터에 대한 가정이 잘못되면 데이터가 손실될 수 있습니다. 현재 시스템에서 디스크는 인식하지만 RAID UI에서 사용할 수 없다면, 중요한 데이터를 백업하고 버전 정보와 함께 문의하세요. lsblk 기존 셸 시퀀스를 그대로 복사하기보다 출력 결과, 컨트롤러 토폴로지, 스크린샷, 현재 어레이 상태를 확인해야 합니다.