커뮤니티가 ZimaOS를 테스트하면서 짧은 답변이 바뀌었습니다
초기 답변에서는 ZimaOS를 기존 패키지 관리자가 없는 최소한의 어플라이언스형 시스템으로 보았습니다. 따라서 apt install이 가능하거나 기본 OS를 영구적으로 수정할 수 있다고 가정하지 말라고 조언했습니다. 더 깔끔한 격리 경계로 Docker와 Debian 또는 Ubuntu 가상 머신이 제안되었습니다.
이후 직접 테스트를 통해 중요한 정정 사항이 추가되었습니다. 한 참가자는 ZimaCube에 /usr/bin/mergerfs와 mergerfs-fusermount가 이미 존재하지만 SnapRAID 바이너리는 찾을 수 없었다고 확인했습니다. 또 다른 참가자는 부팅 경쟁 상태를 디버깅하는 과정에서 기본 제공 mergerfs가 오래된 버전임을 확인했습니다. 따라서 결론은 “네이티브 설치가 불가능하다”가 아니라 “호스트를 수동으로 변경하는 방식은 지원되지 않으며 버전에 따라 달라진다”였습니다.
수동 바이너리는 작동했지만 업데이트 위험이 있었습니다
한 사용자는 WSL2에서 실행 파일을 빌드한 뒤 ZimaOS로 복사하고, 데이터 디스크 2개와 패리티 디스크 1개로 구성된 환경이 작동한다고 보고했습니다. mergerfs 관리자는 정적 빌드가 수동 배포를 단순화할 수 있지만, 컨테이너 동작은 FUSE 마운트를 필요한 방식으로 노출할 만큼 런타임에 충분한 루트 권한이 있는지에 따라 달라진다고 설명했습니다.
커뮤니티 답변에서는 변경 불가능한 시스템 스타일의 환경에 바이너리를 복사하면 유지 관리 부담이 생긴다고 거듭 경고했습니다. OTA 업데이트가 수동 변경 사항을 덮어쓰거나 충돌을 일으킬 수 있으며, 사용자가 실험하는 동안 AI가 생성한 Linux 지침에도 오류가 있었습니다.
커뮤니티가 systemd-sysext 레이어를 구축했습니다
이후 한 기여자가 ZimaOS용 커뮤니티 systemd-sysext 프로젝트를 공개했습니다. 이 프로젝트의 목적은 읽기 전용 기본 시스템을 직접 수정하는 대신 별도의 확장 레이어로 mergerfs와 SnapRAID를 추가하는 것이었습니다.
통제된 ZimaCube Pro 테스트에서는 이 레이어가 정상적으로 로드되고 mergerfs 2.42.0과 SnapRAID 14.5를 제공하며, 임시 mergerfs 풀을 마운트할 수 있음이 확인되었습니다. 테스터는 풀 경로를 통해 파일을 만들고, 마운트를 정상적으로 해제하기 전에 해당 파일이 기본 브랜치에 나타나는지 확인했습니다.
이 테스트에는 전체 SnapRAID 패리티 및 복구 실험이 포함되지 않았습니다. 또한 테스터는 실제 디스크에 실수로 작업이 수행되지 않도록 설정하기 전에 기본 타이머와 서비스를 비활성화했습니다.
두 가지 부팅 경쟁 상태가 발견되어 수정되었습니다
재부팅 후 한 사용자는 풀이 간헐적으로 실패하지만 나중에 수동으로 시작하면 정상 작동한다는 사실을 확인했습니다. 확장 기능 작성자는 두 가지 별도의 경쟁 상태를 찾아냈습니다. 첫째, 기존 검사 로직이 기본 OS에서 제공하는 오래된 mergerfs 바이너리를 감지해 확장 기능의 최신 바이너리가 병합되기 전에 풀을 시작했습니다. 수정된 검사 로직은 확장 기능에서만 제공되는 SnapRAID를 확인하도록 변경되었습니다.
둘째, 물리 브랜치 디스크가 마운트되기 전에 mergerfs가 성공을 반환할 수 있었고, 그 결과 나중에 연결되는 스토리지를 가리는 빈 풀이 생성될 수 있었습니다. 단순한 Restart=on-failure 루프만으로는 성공했지만 비어 있는 상태를 감지할 수 없었습니다. 프로젝트에는 각 브랜치 마운트를 기다리고, 누락된 브랜치 위에 풀을 구성하지 않도록 하는 명시적 검사가 추가되었습니다.
작성자는 이러한 변경 후 ZimaOS 1.6.1에서 콜드 부팅 검증을 완료했다고 보고했습니다. 4베이 TerraMaster 인클로저를 사용하는 한 사용자도 디스크가 마운트되는 데 거의 1분이 걸린 뒤 풀이 결국 나타났다고 보고했습니다.
SnapRAID의 안전성은 여전히 운영자의 검토가 필요합니다
이 확장 기능에는 예기치 않게 많은 파일이 삭제된 경우 동기화를 중지하도록 설계된 삭제 임계값이 포함되어 있었습니다. 이후 한 사용자는 수천 개의 파일을 의도적으로 삭제한 뒤 해당 임계값을 어떻게 재정의할 수 있는지 질문했습니다. 이 운영상의 문제는 스레드에서 해결되지 않았습니다.
이 프로젝트를 평가하는 사람은 자동 작업을 활성화하기 전에 브랜치 경로, 패리티 경로, 타이머, 삭제 임계값 및 애플리케이션 데이터의 위치를 검토해야 합니다. 바이너리 확인이 성공했거나 mergerfs 마운트가 정상적으로 되었다고 해서 운영 데이터셋에 대한 패리티 복구가 테스트되었다는 의미는 아닙니다.
지원 범위
이 방식은 커뮤니티가 구축한 고급 통합 기능이며, IceWhale이 지원하는 ZimaOS 스토리지 기능이 아닙니다. Docker, 전체 Linux 가상 머신, 정적 바이너리 및 sysext는 각각 권한과 지속성 특성이 다릅니다. 이 스레드에서 가장 중요한 결과는 테스트된 확장 기능 방식이지만, 실제 데이터를 도입하기 전에 반드시 폐기 가능한 스토리지에서 평가해야 합니다.
FAQ
mergerfs는 이미 ZimaOS에 포함되어 있나요?
한 참가자가 자신의 ZimaCube에서 mergerfs 바이너리를 확인했습니다. 이후 스레드에서는 해당 기본 제공 버전이 오래된 버전임을 확인했으므로, 바이너리가 존재한다고 해서 최신 구성과의 호환성이 보장되는 것은 아닙니다.
SnapRAID 복구가 완전히 테스트되었나요?
아니요. 통제된 테스트에서는 설치와 임시 mergerfs 풀만 확인했으며, 전체 SnapRAID 패리티 및 복원 테스트는 명시적으로 진행하지 않았습니다.
실패한 서비스를 기다리는 것만으로는 왜 충분하지 않았나요?
한 경쟁 상태에서는 종료 코드가 성공으로 반환되면서 빈 풀이 생성될 수 있었습니다. 이는 실패가 아니므로, 실패 시 재시작 규칙만으로는 이러한 상태를 놓칠 수 있습니다.
