主なユース ケースが VM イメージまたはデータベースの格納であり、btrfs のデータ整合性の利点を得るために潜在的なパフォーマンスの問題を受け入れることに関心がない場合、btrfs を選択する理由が思い浮かびません。 xfs または ext4 経由。
VM イメージの格納がファイル システムの多くの用途の 1 つに過ぎない場合、VM イメージ ディレクトリのみに対してコピー オン ライトを無効にする (chattr +C を使用) ことは、最も重要です。次に、その 1 つのディレクトリに対してコピー オン ライトを無効にするだけで非常に便利な場合がありますが、残りのファイル システムに対しては btrfs のすべての利点が保持されます。
BTRFS には、一部の書き込みパターンで他のファイル システムよりも優れたオン ディスク フォーマットがあります。特に、メタデータをディスクに書き込む方法を改善するために多大な努力が費やされており、データ チェックサム、圧縮、スナップショットなどの高度な機能がサポートされています。大きなファイルの場合、メタデータのパフォーマンスを向上させることは一般的に重要ではありません。
ZFS と比較して、BTRFS はよりシンプルなソリューションであり、Linux でより適切にサポートされています。主な欠点は、(多数のディスクを追加する場合) 拡張性が低く、同じ機能セットがないことです。
XFS と比較すると、パフォーマンスの低いソリューションになります。つまりデータのチャンクをディスクに書き込むのにより多くのプロセッサ時間がかかり、最大スループットが制限されます。これは、チェックサム検証を無効にするなどのことを行うことである程度軽減できますが、メタデータ情報が改善されるという XFS に対する BTRFS の主な利点が失われます。つまりチェックサムとさまざまなジャーナリング (状況によってはこちらの方がよい場合もあります)。
コピー オン ライト (COW) のサポートに関しては、XFS は厳密な COW よりもパフォーマンスを優先します。つまりXFS は、スケーラビリティの点で非常に優れたメタ データとジャーナリング機能を備えており、通常、書き込み時にファイル データを上書きしません。ただし、アプリケーションがデータの上書きを明確に要求した場合に、既存のディスク ブロックを上書きできるという例外があります。これは VM の場合に適しています。最初のディスク割り当ては連続している可能性があり、その場合は VM の存続期間中連続したままになるからです。
nodatacow でも BTRFS を使用 同様に、CoW を使用して手動でデータのスナップショットを作成することもできます そのため、高速でメモリをあまり消費しません。さらに、これらのスナップショットは、LVM を使用するよりも柔軟性があります。ファイル システムが認識していないファイル システムの下にスペースを確保する必要がなく、必要がなければ使用できないからです。 ZFS と同様に、スナップショットはネットワーク経由で送受信できるため、バックアップ戦略の改善に役立つ場合があります。だから nodatacow でも BTRFS は、LVM を使用するよりも優れているようです。