이 소스에서는 최종적으로 IceWhale의 근본 원인이 확인되었습니다. ZimaOS 1.5.3으로 업그레이드한 후 NVMe RAID 어레이 자체는 구성되고 마운트되었지만, zimaos-local-storage RAID 데이터베이스에 다음 값이 포함되어 있었기 때문에 즉시 마운트 해제했습니다. fs_type = 'BTRFS' 소문자로 예상된 값 대신 대문자로 저장되어 있었습니다.
IceWhale의 Dina는 SQLite를 대상으로 한 해결 방법을 제공했습니다. 원 게시자는 이를 실행한 후 RAID가 정상적으로 마운트되었다고 명시적으로 확인했습니다. 이후 ZimaOS 1.5.4에서는 대문자 BTRFS RAID 자동 마운트 문제를 공식 수정 항목으로 기재했습니다. 따라서 현재 사용자는 이 SQL을 정확히 해당 버그에 대한 과거의 복구 지침으로만 간주해야 하며, 일반적인 RAID 복구 명령으로 사용해서는 안 됩니다.
스토리지 관리자가 마운트 해제하기 전 RAID 어레이는 정상 상태였습니다
저널에는 커널이 RAID를 자동 감지하고 systemd가 다음을 마운트하는 과정이 표시되었습니다. /media/RAID-Storage-2그런 다음 zimaos-local-storage 몇 초 후 강제로 마운트 해제했습니다.
원본 데이터베이스 레코드에도 RAID가 다음과 같이 표시되었습니다. 상태 정상. 그러면 장애가 발생한 멤버나 손상된 Btrfs 파일 시스템일 가능성은 낮아집니다.
수동 fstab 설정은 임시 해결 방법으로만 작동
사용자가 RAID를 수동으로 마운트하고 다음 항목을 추가했습니다. /etc/fstab 항목이 있었지만 ZimaOS 스토리지 관리에서는 이를 권위 있는 구성으로 취급하지 않았습니다. 재부팅하면 local-storage 서비스가 내부 데이터베이스/상태를 계속 적용했습니다.
따라서 어플라이언스가 관리하는 스토리지는 일반적으로 병렬 수동 마운트로 유지 관리하기보다 ZimaOS 스토리지 계층을 통해 복구해야 합니다.
커뮤니티에서 zimaos-local-storage가 해당 계층임을 정확히 확인
IceWhale이 근본 원인을 게시하기 전에 gelbuilding은 마운트가 성공한 다음 zimaos-local-storage 마운트 해제합니다. 그는 RAID 메타데이터를 반복해서 수정하기보다는 IceWhale에 로그를 보내라고 올바르게 안내했습니다.
더 엄격한 검증에 대한 그의 추측은 최종 진단이 아니었으며, 이후 공식 진단은 훨씬 더 구체적이었습니다.
IceWhale에서 fs_type 대소문자 오류를 발견
Dina는 데이터베이스가 fs_type 값이 대문자로 되어 있어 마운트에 실패했습니다. IceWhale은 다음 명령을 제공했습니다.
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"사용자는 나중에 “이 방법으로 실제로 문제가 해결되었습니다.”라고 답했습니다.
BTRFS 소문자로 btrfs.ZimaOS 1.5.4에서 동일한 자동 마운트 버그를 공식적으로 수정
1.5.4 릴리스 노트에는 RAID 데이터베이스 레코드에 저장된 BTRFS 대문자로
공식 ZimaOS 1.5.4 RAID 마운트 수정 사항을 참조하세요.
이후 1.5.4 사용자도 RAID가 마운트되지 않는다고 보고했습니다
다른 참여자는 자신의 1.5.4 시스템에서도 마운트 문제가 여전히 발생했다고 말했습니다. Dina는 여전히 대문자 fs_type 버그라고 단정하지 않고 최신 디스크 진단 정보와 증상 설명을 요청했습니다.
이것이 올바른 경계입니다. 비슷한 증상이라도 원인은 다를 수 있습니다.
일치하는 증거 없이 현재 RAID에서 이전 SQL을 실행하지 마세요
현재 ZimaOS 버전은 1.7.1입니다. 다음을 건드리기 전에 local-storage.db다음을 확인하세요:
- 어레이가 실제로 조립되는지;
- journal에 local-storage 서비스가 해당 어레이를 마운트 해제한 것으로 표시되는지;
- 데이터베이스에 실제로 과거의 대문자 값이 포함되어 있는지;
- 현재 백업과 진단 보고서가 있는 경우
이 조건들이 일치하지 않는다면 데이터베이스를 편집할 경우 다른 스토리지 문제의 복구가 더 어려워질 수 있습니다.
사용자가 올바른 로그를 제공했기 때문에 공식 수정 사항을 찾을 수 있었습니다
IceWhale은 다음을 요청했습니다 /ZimaOS-HD/.log/casaos/local-storage.log 커뮤니티에서 스토리지 관리자 계층을 확인한 후에 말입니다. 이 로그 덕분에 팀은 광범위한 추측에서 정확한 대소문자 버그를 찾아낼 수 있었습니다.
현재 마운트 실패가 발생한 경우에는 메타데이터를 수정하기 전에 RAID 조립 상태, journal 로그, ZimaOS 스토리지 상태 및 로컬 스토리지 진단 정보를 동일한 방식으로 보존하세요.
수동으로 데이터베이스를 편집하기 전에 내부 메타데이터를 백업하세요
원본 SQL은 알려진 1.5.3 결함을 수정하기 위해 IceWhale이 제공한 한 줄짜리 수정 명령이었습니다. 다시 직원 안내에 따른 데이터베이스 편집이 필요해진다면 먼저 데이터베이스/상태를 백업하고, 수정 대상인 정확한 조건에만 적용하세요.
RAID 레코드에 대한 광범위한 SQL 업데이트는 스토리지 관리자가 인식하는 상태와 실제 어레이의 연결을 끊어, 복구 가능한 마운트 버그를 메타데이터 복구 문제로 바꿀 수 있습니다.
정상적으로 작동하지만 마운트되지 않는 RAID에 재설치는 첫 번째 대응이 아닙니다
어레이 자체가 정상적으로 조립되었고 데이터도 온전했으므로, RAID를 재설치하거나 다시 생성하는 것은 불필요하고 파괴적인 조치였을 것입니다. 정상적인 어레이가 관리 메타데이터 때문에 거부되는 경우에는 어레이 구성을 건드리기 전에 관리 계층을 복구하거나 공급업체 지원을 받으세요.
RAID 마운트 FAQ
원본 환경에서 RAID 자체가 손상되었나요?
아니요. ZimaOS 스토리지 관리자가 어레이를 마운트 해제하기 전에 어레이가 조립되고 마운트되었습니다.
확인된 근본 원인은 무엇이었나요?
RAID 데이터베이스에 저장된 값은 fs_type 대문자로 BTRFS 소문자 대신 btrfs.
IceWhale은 이 문제를 릴리스에서 수정했나요?
예. ZimaOS 1.5.4에는 대문자 BTRFS 자동 마운트 버그가 수정되었다고 명시되어 있습니다.
