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メディアボリュームとは、機能一覧が最も長いものではなく、機能一覧が役に立たなくなった日にも、予測可能な形で復旧できるものです。
製品比較
もっと読む

Jellyfin内蔵バックアップとファイルレベルバックアップ:どちらを使うべき?
便利なアプリ状態の復元にはJellyfin内蔵のバックアップを使用し、ホストやデプロイメントのより広範な状態も復元する必要がある場合は、停止した状態でファイルレベルのバックアップを使用してください。

KodiとJellyfinの併用 vs スタンドアロンのJellyfinクライアント:どちらが適している?
クライアント側の状態管理を重視するカスタマイズ可能なテレビ中心のワークフローにはKodiを、よりシンプルで複数デバイスに対応したサーバー主導の利用にはスタンドアロンのJellyfinクライアントを選択してください。

JellyfinのCPUコア数を増やすと、実際にいつ高速化するのか?
Jellyfinでコア数を増やす効果があるのは、制御された低コア数の候補がCPUバウンドになり、同じワークロードがより大きなプロセッサでスケールする場合に限られます。

