이 2025년 ZimaOS 기능 요청 스레드에서 가장 강력한 주장은 단순히 “파일 시스템을 하나 더 추가해 달라”는 것이 아니었습니다. 사용자들은 Unraid와 유사한 스토리지 모델을 원했습니다. 즉, 서로 다른 용량으로 개별 포맷된 디스크를 그대로 유지하면서 하나의 논리 풀로 제공하고, 전체 디스크를 기존의 스트라이프 RAID 어레이로 변환하지 않고 패리티 보호를 추가하는 방식입니다.
Zima-Giorgio는 ZimaOS 1.4.2에 추가될 예정인 JBOD 옵션으로는 왜 충분하지 않은지 질문하고, 구체적인 실제 사용 흐름을 요청했습니다. 답변을 통해 차이가 분명해졌습니다. JBOD는 용량을 결합할 수 있지만, MergerFS와 SnapRAID 조합은 풀링과 예약된 패리티 생성을 분리합니다. 또한 사용자는 서로 다른 용량의 드라이브를 수년에 걸쳐 추가하면서 홈 미디어 컬렉션을 확장할 수 있습니다.
홈 NAS 사용자가 MergerFS와 SnapRAID를 요청한 이유
여러 참여자는 저장 공간이 조금씩 늘어나는 상황을 설명했습니다. 한 사용자는 3TB, 6TB, 12TB 드라이브를 보유하고 있었습니다. 또 다른 사용자는 8TB 드라이브로 메인 NAS의 6TB 디스크를 교체하고, 분리한 6TB 디스크를 아카이브 시스템으로 옮긴 뒤, 기존 아카이브 디스크를 다시 홈 랩 서버로 옮기는 흐름을 설명했습니다.
기존 RAID는 이러한 패턴에 불편할 수 있습니다. 사용 가능한 용량과 확장 규칙이 대개 용량이 같거나 사전에 신중하게 계획된 드라이브를 전제로 하기 때문입니다. 사용자는 더 큰 디스크를 구매할 때마다 전체 어레이를 다시 구축하는 대신, 기존 디스크의 가치를 계속 활용하고 싶어 했습니다.
MergerFS와 SnapRAID는 서로 다른 문제를 해결합니다
MergerFS는 유니언 파일 시스템입니다. 여러 독립 파일 시스템을 하나의 논리 마운트 지점 아래에 표시하면서도 파일은 각 구성 디스크에 개별적으로 저장할 수 있습니다.
SnapRAID는 패리티 소프트웨어입니다. 데이터 디스크의 파일에서 패리티 정보를 계산하고 무결성 검사를 제공할 수 있습니다. 패리티 동기화는 일반적으로 기존 RAID처럼 지속적으로 기록되는 것이 아니라 예약된 작업으로 실행됩니다.
이러한 분리 덕분에 두 기술의 조합은 비교적 정적인 미디어 컬렉션에서 인기가 높습니다. MergerFS는 풀 네임스페이스를 제공하고, SnapRAID는 선택한 디스크 장애로부터 복구할 수 있도록 해 줍니다.
ZimaOS JBOD가 같은 설계가 아닌 이유
현재 ZimaOS 문서에서는 JBOD를 여러 드라이브를 하나의 연속 볼륨으로 결합하는 기능으로 설명합니다. 이는 용량 확장 옵션이지, 사용자가 요청한 것과 같은 패리티 모델은 아닙니다.
현재 기본 제공되는 선택지를 비교하려면 ZimaOS에서 사용할 수 있는 RAID 및 JBOD 옵션을 확인하세요. JBOD는 단순한 풀 용량이 목적일 때 유용하지만, 구성 디스크의 용량이 서로 다르다고 해서 SnapRAID가 되는 것은 아닙니다.
MergerFS 개발자가 토론에 참여했습니다
MergerFS 개발자인 Trapexit은 CasaOS가 과거 “merge” 스토리지 기능에 MergerFS를 사용했다고 설명했습니다. 그는 이전에 IceWhale과 더 깊은 통합을 논의한 적이 있었지만, 당시에는 이러한 대화가 더 광범위한 ZimaOS 통합으로 발전하지 않았다고 말했습니다.
또한 그는 MergerFS에 적합한 작업 부하를 합리적으로 설명했습니다. 파일을 한 번 기록하고 여러 번 읽으며 변경이 드문 환경에서는 높은 랜덤 쓰기 성능보다 독립 파일 시스템을 하나의 논리 풀로 묶는 것이 더 중요하다는 것입니다.
스레드 후반에 CasaOS의 병합 화면이 등장했습니다
이 스크린샷은 CasaOS의 사례일 뿐이며, 현재 지원되는 ZimaOS MergerFS 관리 페이지가 있음을 입증하는 자료는 아닙니다.
사용자가 SnapRAID를 실시간 패리티와 다르게 보는 이유
스레드에서는 파일이 지속적으로 변경되지 않는 미디어 아카이브가 반복해서 논의되었습니다. 예약된 패리티 작업을 사용하면 사용하지 않는 디스크를 더 자주 절전 상태로 둘 수 있고, 모든 디스크가 모든 읽기 작업에 참여하도록 요구하지 않아도 됩니다. 또한 사용자는 SnapRAID의 무결성 검사를 통해 무음 데이터 손상을 감지할 수 있다는 점도 중요하게 여겼습니다.
다만 마지막 패리티 동기화 이후 발생한 변경 사항은 해당 패리티 스냅샷으로 보호되지 않습니다. 따라서 SnapRAID는 모든 RAID 작업 부하를 그대로 대체하는 방식이 아닙니다.
IceWhale이 실제로 약속한 내용
공식 답변은 신중했습니다. Zima-Giorgio는 먼저 MergerFS와 SnapRAID가 JBOD와 비교해 왜 대체 불가능한지 사용자가 설명해 달라고 요청했습니다. 2025년 11월에는 팀이 피드백을 전달받았으며 해당 요청을 재검토하겠다고 밝혔습니다.
이는 제품 출시 약속, 로드맵 일정 또는 릴리스 발표와는 다릅니다.
현재 상태
현재 ZimaOS 스토리지 문서는 단일 디스크, JBOD, RAID 및 ZFS 관련 기본 제공 선택지를 중심으로 구성되어 있습니다. ZimaOS Storage UI에는 현재 공식 SnapRAID 구성 페이지가 없습니다.
2026년 이후 커뮤니티 조사에서는 일부 ZimaOS 시스템에 MergerFS 바이너리가 존재하고, MergerFS와 SnapRAID를 패키징한 커뮤니티 systemd-sysext 프로젝트가 확인되었습니다. 이는 의미 있는 발전이지만, 지원되는 ZimaOS UI와 수명 주기 관리가 포함된 자사 공식 SnapRAID 지원과 같은 것은 아닙니다.
작업 부하에 따라 스토리지 모델을 선택하세요
- 용량이 같은 드라이브와 지속적인 이중화: 필요한 장애 허용 수준에 맞는 ZimaOS RAID 옵션을 사용하세요.
- 패리티가 필요 없는 단순한 용량 통합: JBOD로 충분할 수 있습니다.
- 서로 다른 용량의 비교적 정적인 미디어와 예약된 패리티: 이 스레드의 사용자들이 요청한 작업 흐름은 MergerFS와 SnapRAID의 조합입니다.
- 자주 변경되는 중요 데이터: 어레이 기술과 관계없이 별도의 백업을 유지하세요.
패리티는 백업이 아닙니다
이 요청은 실수로 인한 삭제, 랜섬웨어 또는 서버 전체의 파괴가 아니라 드라이브 장애를 견디는 것에 관한 것입니다. MergerFS와 SnapRAID를 함께 사용하는 설계에도 대체할 수 없는 데이터를 위한 별도의 백업 계획이 필요합니다.
MergerFS 및 SnapRAID FAQ
IceWhale은 공식 SnapRAID 지원을 발표했나요?
아니요. 팀은 사용 사례를 요청했고, 이후 피드백을 재검토하겠다고 밝혔습니다.
ZimaOS JBOD는 MergerFS와 SnapRAID의 조합과 같은 기능인가요?
아니요. JBOD는 용량 통합이고, 요청된 설계는 유니언 파일 시스템과 패리티 동기화를 결합합니다.
ZimaOS에 MergerFS 관련 커뮤니티 작업이 있나요?
예. 하지만 커뮤니티 바이너리와 sysext 모듈을 공식 SnapRAID 관리 기능으로 설명해서는 안 됩니다.
