ZFS、Btrfs、ext4はいずれもPlexのデータを保存できますが、最適な選択は、統合された整合性機能、Linuxネイティブのスナップショット、シンプルなファイルシステムのどれを重視するか、また復旧を別の仕組みに任せるかによって異なります。
互換性と復旧モデルから検討する
Plexのパフォーマンスだけを基準にファイルシステムを選ばないでください。ホストOS、プール設計、スナップショットの運用方法、メモリ予算、修復ツール、バックアップ方法によって、ストレージ層の運用しやすさが決まります。
重要なファイルシステムの比較軸は、Plex専用のベンチマークスコアではなく、コピーオンライト、チェックサム、スナップショット、リソース使用量です。
ホストプラットフォームや復旧プロセスで確実にサポートできない選択肢は除外しましょう。機能が多くても、運用担当者が復元できないファイルシステムは、Plexには不向きです。
ストレージプール自体を整合性管理の中心にするならZFS
ZFSは、チェックサム付きデータ、スナップショット、スクラブ、プール化ストレージ、複数ディスクによる保護を設計の中心に据える場合に最も力を発揮します。その代わり、プールを作成する前に計画しておくべき、設計思想の強いストレージ層になります。
ZFSのプールレベルストレージは、ファイルシステムと整合性管理・プール管理機能を統合しています。そのため、サーバーで実際にこれらの機能を活用する場合に最適です。
整合性管理とスナップショットの責任の大部分をファイルシステムとプールに担わせたい、そしてその構成を運用できるなら、ZFSを選びましょう。
LinuxネイティブのスナップショットとCoWワークフローならBtrfs
Btrfsは、ZFSと同じプールモデルを必要とせずに、チェックサム、コピーオンライト、スナップショット、圧縮、サブボリュームをLinuxのファイルシステム層に組み込みます。コンテナやスナップショットのワークフローがすでにBtrfsを中心に構築されているLinuxホストに適しています。
Btrfsのスナップショットとデータチェックサムは復旧と整合性管理のためのツールになります。一方、ハードウェア、冗長性の構成、復元手順は別途決める必要があります。
統合されたLinux機能が実際のワークフロー上の問題を解決し、計画した冗長化モードを運用・復旧できる準備があるなら、Btrfsを選びましょう。
統合機能よりシンプルさを重視するならext4
成熟したシンプルなファイルシステムを使い、スナップショット、冗長性、チェックサム、バックアップを別の層で管理するなら、ext4が最も無難な選択です。
よりシンプルなLinuxサーバーでは、Plexのワークロードが必要としないファイルシステム機能を追加するよりも、ext4のジャーナリングと低い運用負荷のほうが価値を持つ場合があります。
Plexの状態データと大量のメディアデータに、すでに検証済みのバックアップ計画があるなら、ext4で十分なことがあります。メディアサーバーのストレージ構成では、すべてのデバイスに1つのファイルシステムを強制せず、ストレージの役割ごとに異なる構成を使うこともできます。
製品比較
もっと読む

Plex向けの4コアCPUと8コアCPU:混在クライアントの同時接続に適しているのはどちら?
4コアは主にダイレクト再生に適しており、ソフトウェアトランスコードやホスト上の同時実行ジョブが測定済みのしきい値を超えると、8コアのコストに見合う価値が得られます。

専用Jellyfinサーバーと共有アプリホスト:どちらの境界が適している?
メディア処理と復旧の予測可能性を重視するなら専用ホスティングを、ワークロードが軽く分離性を測定できるなら共有ホストを選びましょう。

複数ユーザーでのホームストリーミングにおけるJellyfinとPlexの比較:クライアント対応範囲か、制御性か?
クライアントの対応範囲が決め手ならPlexが優勢で、コントロール性が決め手ならJellyfinが優勢です。ユーザーのニーズが明確に分かれる場合は、どちらも有力な選択肢になり得ます。

