この2025年のZimaOS機能リクエストスレッドで最も強く主張されたのは、単に「別のファイルシステムを追加してほしい」ということではありませんでした。ユーザーが求めていたのは、Unraidに似たストレージモデルです。つまり、サイズの異なるディスクをそれぞれ個別にフォーマットしたまま、1つの論理プールとして扱い、ディスク全体を従来型のストライプRAIDアレイに変換せずにパリティ保護を追加する仕組みです。
Zima-Giorgioは、ZimaOS 1.4.2で予定されているJBODオプションではなぜ不十分なのかを問い、具体的な実際の運用例を求めました。返信から、その違いが明確になっています。JBODは容量を統合できますが、MergerFSとSnapRAIDの組み合わせが魅力的なのは、プール化とスケジュール実行されるパリティ処理を分離でき、サイズの異なるドライブを使って何年にもわたりホームメディアコレクションを拡張できるためです。
ホームNASユーザーがMergerFSとSnapRAIDを求めた理由
複数の参加者が、少しずつ増えていくストレージについて説明しました。あるユーザーは3 TB、6 TB、12 TBのドライブを所有していました。別のユーザーは、メインNASの6 TBディスクを8 TBドライブに交換し、取り外した6 TBディスクをアーカイブシステムへ移し、さらに古いアーカイブ用ディスクをホームラボサーバーへ移すという運用を説明しました。
従来型のRAIDは、使用可能容量や拡張ルールが、同じ容量のドライブや綿密に計画されたドライブ構成を前提としていることが多いため、このような運用では扱いにくい場合があります。ユーザーが望んでいたのは、大容量ディスクを1台購入するたびにアレイ全体を再構築するのではなく、既存ディスクの価値を維持することでした。
MergerFSとSnapRAIDは異なる問題を解決する
MergerFSはユニオンファイルシステムです。複数の独立したファイルシステムを1つの論理マウントポイントの下に表示しながら、ファイル自体は個々のメンバーディスク上に保持できます。
SnapRAIDはパリティソフトウェアです。データディスク上のファイルからパリティ情報を計算し、整合性チェックを提供できます。パリティの同期は通常、従来型RAIDのように継続的に書き込まれるのではなく、スケジュールに従って実行されます。
この分離が、比較的静的なメディアコレクションでこの組み合わせが人気を集めている理由です。MergerFSがプールの名前空間を提供し、SnapRAIDが選択したディスク障害からの復旧性を提供します。
ZimaOSのJBODが同じ設計ではない理由
現在のZimaOSドキュメントでは、JBODは複数のドライブを結合して1つの連続したボリュームにする機能として説明されています。これは容量を統合するための選択肢であり、ユーザーが求めていたパリティモデルと同じものではありません。
現在組み込まれている選択肢については、ZimaOSで利用できるRAIDとJBODのオプションを比較してください。単純に容量をプール化したい場合、JBODは便利です。しかし、メンバーディスクのサイズが異なるからといって、JBODがSnapRAIDになるわけではありません。
MergerFSの開発者が議論に参加
MergerFSの開発者であるTrapexitは、CasaOSが以前から「merge」ストレージ機能にMergerFSを使用していたと説明しました。また、IceWhaleとのより深い統合について以前に話し合ったものの、当時はその協議がZimaOSへの幅広い統合に発展しなかったとも述べています。
さらに、MergerFSに適した妥当なワークロードとして、1度書き込んだ後に何度も読み取られ、変更頻度が低いファイルを挙げました。これは、高いランダム書き込み性能よりも、独立したファイルシステムを論理プールとして扱えることが重要なケースです。
スレッドの後半でCasaOSのMerge画面が登場
このスクリーンショットはCasaOSの証拠であり、現在サポートされているZimaOSのMergerFS管理ページが存在することを示すものではありません。
ユーザーがSnapRAIDをリアルタイムパリティと異なると考える理由
スレッドでは、ファイルが常に変更されるわけではないメディアアーカイブが繰り返し話題になりました。スケジュールされたパリティ処理により、未使用のディスクをより長時間スリープさせられ、すべてのディスクをすべての読み取りに参加させる必要もなくなります。ユーザーは、サイレントデータ破損を検出できるSnapRAIDの整合性チェックも評価していました。
一方で、最後のパリティ同期後に行われた変更は、そのパリティスナップショットでは保護されません。そのため、SnapRAIDはあらゆるRAIDワークロードの代替としてそのまま使えるわけではありません。
IceWhaleが実際に約束したこと
公式の返信は慎重なものでした。Zima-Giorgioはまず、JBODと比較してMergerFSとSnapRAIDがなぜ代替不可能なのかをユーザーに説明するよう求めました。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管理機能として説明すべきではありません。
