Categories
現代のストレージ技術の戦場において、Btrfs とZFS / OpenZFS は間違いなく、最も強力な 2 大勢力として君臨しています。両者ともにCopy-on-Write (CoW) を基盤とし、自己修復やスナップショット機能を提供しますが、物理ストレージ層（例：RAID5/RAID50）やデバイス拡張の扱いにおいては、明確に異なるエンジニアリング DNA を持っています。
この 2 つのファイルシステムの違いを、書き込みメカニズム、拡張コスト、RAID ライトホール、データ整合性という 4 つの主要な観点から見ていきます。
1. 書き込みメカニズムにおける思想の違い：柔軟性 vs. 効率性
Btrfs と ZFS はデータ書き込みの扱いに根本的に異なる戦略を採用しており、この違いがそれぞれの用途を直接決定づけます。
Btrfs：テトリスのような埋め込み方式
Btrfs は物理デバイスを 1 GiB の論理単位「チャンク」として抽象化します。この設計により、現在利用可能なディスクの数に応じて、書き込み時にストライプ幅を動的に決定できます。
主な利点は、卓越したハードウェアの柔軟性です。1 つのプール内で異なる容量のドライブを混在させることができ、Btrfs はテトリスのように空間利用を最大化します。
アーキテクチャ上、独立した RAID50 プロファイルは存在せず、複数の RAID5 チャンクを集約することで、実質的に並列 RAID50 として機能します。
ZFS：トランザクションベースのパフォーマンスロジック
一方、ZFS はパフォーマンス重視の戦略を採用しています。可変ストライプ幅方式を取り、各書き込みトランザクションごとにストライプレイアウトを動的に決定します。
ZFS の利点は、従来の RAID Read-Modify-Write (RMW) サイクルを完全に排除し、I/ O 効率を大幅に向上させる点です。ZFS はフルストライプ書き込みをサポートし、データのサイズに基づいてリアルタイムでパリティを計算し、フルストライプ書き込みを実行することで、パリティがデータ境界をまたがないようにします。
環境に様々な古いドライブが混在している場合、Btrfs のアーキテクチャは異なる世代や容量のドライブの混在に適しています。しかし、最大限の I / O スループットやエンタープライズグレードの一貫性を追求する場合は、ZFS のトランザクションフローアーキテクチャが明確な優位性を持ちます。
2. 拡張コスト：リバランス vs. ダイナミックデータフロー
ストレージ容量が少なくなり、新しいディスクが追加された場合、何が起こるのでしょうか？これは運用チームの間で最も誤解されやすい側面の 1 つです。
Btrfs におけるフルリライトのコスト
新しいディスクを活用し、より広いストライプ幅を実現するために、Btrfs は btrfs バランス操作を実行する必要があります。その影響として、全データのリライト処理が発生します。数テラバイト規模のアレイでは、この処理に数日かかり、かなりの I / O 負荷が発生する場合があります。
その結果、長時間のリライト処理が完了して初めて、データの分布と RAID レベルが完全に変換されます。
ZFS のエレガンスと落とし穴：論理的リフロー
ZFS は拡張時に既存のデータを移動する必要がありません。この挙動は「強制リライトなし」と呼ばれます。この仕組みのもと、ZFS プール Allocator（SPA）は空き容量を監視し、空き容量の多い（新しい）デバイスに新規書き込みを優先的に割り当てます。これは容量重視の重み付き割り当ての一形態です。
しかし、拡張に関してよくある誤解があります。多くの人が、データが拡張後に自動的にリバランスされると誤って信じています。これは正しくありません。既存のデータは元のディスクに残り、リードホットスポットが発生します。新たに追加されたディスクの IOPS は、既存のデータへのアクセス時には限定的な効果しかありません。
このような場合、より良い解決策は、ZFS のリライトを手動で実行するか、新しい RAIDZ Expansion テクノロジーを使用して真のバランスを実現することです。ただし、スナップショットが存在する場合、使用容量が 2 倍になる可能性があることに注意してください。
最新バージョンの OpenZFS には、zpool remove やその他のデバイス変更機能、リバランスに利用できるツールなど、すでにいくつかの機能が搭載されています。簡単に言えば、ZFS の拡張モデルは Btrfs の動的拡張とは異なりますが、完全に静的というわけではありません。
実際の運用では、容量を決定したらそれに合わせて構成し、さらなる拡張を避けるのがより適切な選択です。企業は必要な仕様を事前に見積もり、それに応じて購入することで将来のトラブルを回避すべきです。ただし、これは ZFS の欠点でもあり、RAID セット全体の拡張の柔軟性は Btrfs ほど高くありません。
3. データ整合性の核心的な戦場：RAID ライトホール
「ライトホール」とは、書き込み処理中に電源障害が発生した際に生じる重大なリスクであり、データとパリティの間に不整合が発生する可能性があります。
ZFS：構造的な耐性
ZFS は、いくつかの技術を採用することで、アーキテクチャレベルでこの問題を本質的に防ぎます。最初の技術はアトミックアップデートです。ZFS はトランザクショングループ（TXG）とリングバッファを使用します。システムはリングバッファをスキャンして「有効なチェックサム」を持つ最新の TXG を特定します。電源障害時に書き込み中だった不完全な TXG は完全に無視され、システムは直ちに最後の一貫性のある状態に戻ります。
2 つ目は Merkle Tree です。ファイルシステム全体が巨大なハッシュツリーとして構成されており、基盤となるデータが破損すると、上位レベルのチェックサム検証が失敗し、サイレントなデータの破損を防ぎます。Uberblock はこのツリーの唯一の信頼アンカーとして機能し、決して上書きされることはありません。
Btrfs：実験的ステータスから RST による復権へ
Btrfs RAID5/ 6 は、致命的なライトホール脆弱性のため、長らく「実験的」とラベル付けされていました。
Linux カーネル 6.2 で RAID Stripe Tree（RST）が導入されました。これは、エクステント単位で物理レイアウトを管理する新しいツリー構造で、もともとライトホール脆弱性に対応するために設計されました。それ以前は、Btrfs はチェックサムを検証するためにフルのリード・モディファイ・ライト（RMW）サイクルに依存しており、パフォーマンスのオーバーヘッドが発生していました。
しかし、公式 btrfs readthedocs ステータスページによると （Linux カーネル 6.17 時点）、ほとんどの Btrfs 機能は「OK」または「ほぼ OK」とされています。RAID5/6 は本番環境での使用には依然として不適切であり、ステータステーブルで「OK」とはマークされていません。Linux カーネル 6.12 時点では、実験的機能を利用するには CONFIG_BTRFS_EXPERIMENTAL の有効化が必要であり、既知の問題も残っています。さらに、ライトホールの根本的な原因は完全には解消されていません。現在の実装では特定の書き込み破損シナリオを緩和していますが、長期的な影響については引き続き観察が必要です。
現在主流の Linux カーネル（例：6.x シリーズ）では、Btrfs のネイティブ RAID5/6 サポートは徐々に改善されています。過去数年にわたり、Btrfs コミュニティや開発者によって RAID5/6 実装の既知のバグが修正され、レースコンディションの修正やスクラブ動作の改善が行われてきました。しかし、RAID5/6 のコア実装は依然として完全な成熟や安定性には至っていません。特にデータ復旧やデバイス障害後のリカバリーなど、特定のエッジケースでは信頼性の高い復旧に問題が発生する場合があります。
言い換えれば、最新のカーネルにおける RAID5/6 の扱いは過去よりも成熟してきていますが、RAID1/10 や ZFS の RAID-Z などの成熟した実装が提供する堅牢性にはまだ及びません。そのため、技術的な議論においては、より安定した RAID 構成（RAID1/10 や mdadm で構築し Btrfs を重ねた RAID5/6 など）を代替案として使用し、重要な本番環境で Btrfs のネイティブ RAID5/6 実装に直接依存することは推奨されません。
実際には、Linux カーネル 6.2 以降で Btrfs の書き込みやチェックサム処理の一部が改善されたものの、ライトホールは依然として残っており、特に電源断やデバイス障害を伴うコーナーケースで発生します。同時に、スクラブやバランス操作も依然として遅い場合があり、大容量アレイでは完了まで数日から数週間かかることもあります。
4. スナップショット下のリスク：Btrfs に潜む懸念
スナップショットは CoW ファイルシステムの強力な機能ですが、アレイの拡張や再編成時には負担となる場合があります。ZFS では、データセットとスナップショットは正式に分離されたエンティティです。一方、Btrfs のサブボリュームとスナップショットは、同じ内部名前空間を共有する柔軟性を持っています。
Btrfs のリスクは、多数のスナップショットを保持したままバランス操作を実行することにあります。これらのスナップショットが参照するエクステントを更新すると、遅延参照（delayed refs）の爆発を引き起こす可能性があります。これによりパフォーマンスがゼロまで低下し、メタデータ検証の失敗によってファイルシステムがマウントできなくなる重大な事故も発生しています。しかし、これらの多くの問題は新しい Btrfs リリースや最近の Linux カーネルバージョンで緩和されています。
ZFS の堅牢性は、そのブロックポインタが不変であることに表れています。リフローは RAID レイヤーで物理レイアウトのみを調整し、スナップショットなどのファイルシステムレベルの機能とは独立しています。数千のスナップショットがあっても、アレイの拡張によってメタデータの整合性が脅かされたり、パフォーマンスが崩壊したりすることはありません。
エンタープライズユーザーと家庭ユーザーはどのように選ぶべきか？
エンタープライズ環境で Btrfs の適合性を評価する際の重要なポイントは、高度な機能を提供するかどうかではなく、最悪のケースにも耐えうるストレージ基盤として適しているかどうかです。エンジニアリングの観点から見ると、Btrfs は RAID1、RAID10、またはシングルディスクおよびマルチコピー構成で既に十分に成熟しており、Linux ディストリビューションにおけるシステムディスク、イメージ管理、スナップショットロールバックのシナリオで広く利用されています。
しかし、ストレージ要件がエンタープライズで最も重視される容量効率や耐障害性（例：RAID5/6）に向かう場合、Btrfs のリスクモデルは、予測可能な障害モードやデータのリカバリ信頼性に対するエンタープライズの期待を完全には満たさない可能性があります。Btrfs RAID5/ 6 は、現行主流の Linux カーネル 6.x シリーズで既知の問題の一部が徐々に解決されてきているものの、その実装は依然として重要な本番環境では推奨されないと明示されています。そのため、一部の企業は、インシデント対応、責任範囲の明確化、長期的な運用・保守において追加の不確実性を受け入れるかどうかを検討することになります。
総じて、Btrfs は「エンタープライズ利用に不適」というわけではなく、システム層やプラットフォーム層、または上位保護を提供するストレージアーキテクチャ内でより適した位置付けとなります。一方で、コアとなるエンタープライズデータを担い、長年の安定運用が求められ、RAID5/ 6 の容量効率に大きく依存するシナリオでは、より高いエンジニアリング成熟度とリスク制御性を持つソリューションを優先すべきです。
対照的に、ZFS はエンタープライズ環境でより明確な役割を持っています。そのコア設計は、システムが長期にわたり重要なデータを担い、ハードウェア障害や電源異常、複数ディスクの同時障害などの極限状況下でもデータの一貫性とリカバリ性を維持することを前提としています。
ZFS は、ファイルシステムとディスク管理を単一のストレージスタックに統合します。エンドツーエンドのチェックサム、Copy-on-Write、RAID- Z の密接な連携により、予測可能な障害モードと成熟した自己修復プロセスを確立します。これらはまさに、エンタープライズが最も重視するエンジニアリング特性です。
したがって、ZFS はミッションクリティカルなエンタープライズストレージ、仮想化バックエンド（例：VM やコンテナボリューム）、大規模な NAS 展開、バックアップリポジトリに特に適しています。特に RAID5/ 6 のようなパリティベースのアーキテクチャが必要で、容量効率とデータ整合性のバランスが求められる環境では、ZFS はほとんどの汎用ファイルシステムよりも優れた安定性と予測可能な障害挙動を提供します。
もちろん、ZFS はより高いハードウェア要件、全体的なコスト増加、より厳格な拡張モデルというコストが伴います。しかし、エンタープライズ規模では、予測可能性のためにリソースをトレードオフするという設計思想は、長期運用や規制遵守、リスク管理を重視する組織にとって受け入れやすい場合が多いです。
両ファイルシステムにはそれぞれ強みがあります
RAID- Z モデルを統合する際、ZFS はエンドツーエンドのチェックサムと自己修復機構を提供しますが、Btrfs は主に RAID 構成とスクラブ操作による検証に依存しています。ただし、Btrfs はメタデータや RAID5/ 6 のシナリオで依然として明確な制限とリスクを抱えています。
ZFS は比較的高い RAM 要件があり、特に重複排除を有効にすると顕著です。これは導入時に慎重に検討する必要があり、全体のシステムコストを増加させる要因となります。特にメモリ価格が高い時代には大きなコスト要因となりますが、その代わりにより高いパフォーマンスと強力なデータ整合性を提供します。
以下は、2 つのファイルシステムの主な違いの比較です：
| ファイルシステム | Btrfs | ZFS |
| ハードウェアの柔軟性 | ディスクの混在をサポート | より制限あり（VDEV 制約） |
| 拡張への影響 | 高い（バランスによる完全な書き換えが必要） | 低（リフロー、書き換え不要。ただしリードホットスポットの監視が必要） |
| ライトホールプロテクション | Linux カーネルバージョン（6.2+ RST）に依存 | アーキテクチャの耐性（アトミック TXG） |
| スナップショット拡張の安定性 | リスク（ディレイドリファレンスの爆発） | 安全（イミュータブル BP） |
「データ保護」と「長期的な信頼性」が絶対条件となる大規模環境では、OpenZFS が最適な選択肢です。その安定性に加え、Merkle Tree やアトミックアップデートにより、数学的に検証可能な整合性を提供します。
ただし、柔軟なディスク管理が必要な経験豊富な Linux ユーザー（例：ホームラボで容量の異なる古いドライブを混在させる場合）や、カーネルバージョンの互換性や運用の詳細を管理できる方には、Btrfs が大きな柔軟性を提供します。
どちらを選択する場合でも、SMR ドライブは NAS 環境で絶対に使用しないでください。可能な限り、必ず CMR ドライブを指定してください。これは、SMR ドライブはランダム書き込み性能が比較的低く、頻繁な書き込み用途には不向きだからです。HDD メーカー（Western Digital や Seagate Technology など）は、容量のボトルネックを突破するために、Microwave-Assisted Magnetic Recording（MAMR）や Heat-Assisted Magnetic Recording（HAMR）などの次世代技術を進めており、新しいドライブモデルにもこれらの技術が採用されます。
権限の許可を得て再掲載CyberQ
