JellyfinメディアボリュームにはZFS、Btrfs、ext4のどれが適している?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

ZFS、Btrfs、ext4はいずれも、一般的な再生に十分な速度でJellyfinのメディアを保存できます。そのため、ファイルシステムの選択で重要なのは映画ストリームのスループットよりも、チェックサム、スナップショット、冗長性、レプリケーション、修復ツール、運用の複雑さをどこで担わせたいかという点です。

この比較は、バルクメディアボリュームを対象としています。JellyfinのアプリデータとSQLiteデータベースはランダムI/Oの特性が異なるため、すべてのストレージ用途に同じファイルシステム方針を強制するのではなく、別々に容量設計とチューニングを行うべきです。

メディアプール自体をインテグリティシステムにするならZFS

ZFSは、ファイルシステム、ボリューム管理、チェックサム、スナップショット、スクラブ、RAIDZまたはミラーを1つのストレージモデルに統合します。複数ディスクのメディアプールでデータ破損を検出し、冗長性によって正常なコピーから破損ブロックを修復したい場合に適しています。

OpenZFSのドキュメントでは、中核となるインテグリティ機能が直接説明されています。すべてのブロックにチェックサムが付与され、スクラブによってプールが検証され、冗長なミラーまたはRAIDZによって正常なコピーから破損データを修復できます。そのため、メディアプール自体にインテグリティと修復の責任を担わせたい場合、ZFSは有力な選択肢です。

スナップショット、スクラブ、レプリケーション、冗長性を実際に運用する機能として必要とするなら、ZFSを選びましょう。メディアサーバーのガイドで「エンタープライズ」と呼ばれているからという理由だけで選ぶべきではありません。

LinuxネイティブのスナップショットとチェックサムのワークフローならBtrfs

BtrfsはLinuxに統合されており、コピーオンライト、データおよびメタデータのチェックサム、スナップショット、圧縮、send/receiveを提供します。単一のメディアディスクやミラー、またはコンテナやホストのワークフローもファイルシステムで支える汎用Linuxサーバーに適しています。

Btrfsのドキュメントでは、スナップショット、データとメタデータのチェックサム、圧縮、ボリューム管理、自己修復機能を備えたコピーオンライトストレージについて説明されています。ext4よりも機能豊富なファイルシステムを選ぶ理由は、Linuxネイティブのメディアホストにこれらの機能を統合できることです。

冗長性プロファイルは慎重に選んでください。実効容量を最大化する機能を選ぶのではなく、自信を持って復旧できるレイアウトを使用しましょう。

ファイルシステムをシンプルに保ちたいならext4

ext4は、Linuxで幅広くサポートされている成熟したジャーナリングファイルシステムで、使い慣れた修復ツールを利用できます。ZFSのようなエンドツーエンドのデータチェックサムやネイティブのファイルシステムスナップショットは提供しないため、それらの役割はmdraid、LVM、バックアップソフトウェア、NASレイヤー、または別のツールに担わせる必要があります。

Linuxカーネルのドキュメントでは、ext4のジャーナルを、クラッシュ後もファイルシステムのメタデータ整合性を保護する仕組みとして説明しています。ext4は、ZFSと同じ統合型のプール、スナップショット、エンドツーエンドのインテグリティモデルを提供しようとはしないため、これらの責任を他のレイヤーで明確に処理する場合に最適です。

メディアライブラリがすでにバックアップされており、ファイルシステムを主な復旧基盤にする必要がない場合、このシンプルさは大きな価値になります。

Jellyfinのメディアスループットがこの比較を決めることはほとんどない

Direct Playの映画は、ほとんどの場合、シーケンシャル読み取りです。適切なストレージ上にある健全なファイルシステムなら、一般的なメディアビットレートを上回れるため、ベンチマークのわずかな差を選択の決め手にすべきではありません。

複数のストリーム、スキャン、ダウンロード、バックアップ、スナップショット、その他のサービスが同じプールにアクセスすると、ワークロードは変化します。その時点では、Jellyfinのプロセス自体よりも、レイアウト、ドライブ数、キャッシュの挙動、断片化、復旧方針のほうが重要になります。

ZimaSpaceのスナップショットによるBtrfsメタデータの増大に関するガイドは、高度なファイルシステム機能が復旧手段だけでなく、保守の責任も生み出すことを思い出させてくれます。

障害と復旧のワークフローで選ぶ

優先事項 まず検討するもの 理由
統合されたマルチディスクのインテグリティとRAIDZ ZFS チェックサム、スクラブ、スナップショット、プールレベルの冗長性
LinuxネイティブのCoW、スナップショット、柔軟な単一ディスクまたはミラー運用 Btrfs スナップショット、チェックサム、send/receive
シンプルで成熟したファイルシステム、復旧は別のレイヤーで処理 ext4 ストレージポリシーの複雑さを抑えられる

どのファイルシステムを選んでも、実際のバックアップを用意してください。スナップショットやRAIDによって一部の障害リスクは軽減できますが、削除、ランサムウェア、プールの壊滅的な損失、管理操作のミスに備える独立したコピーの代わりにはなりません。

障害モードと復元ツールを実際に練習できるファイルシステムを選びましょう。最適なJellyfinメディアボリュームとは、機能一覧が最も長いものではなく、機能一覧が役に立たなくなった日にも、予測可能な形で復旧できるものです。

製品比較

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.