Categories
ストレージ技術の最前線において、Btrfs（B-tree File System）とOpenZFSは常に比較の対象となります。
どちらも「コピーオンライト（CoW）」という強力な基盤を持ち、スナップショットや自己修復機能を備えていますが、その内部実装、特にRAID5相当の構成（RAID50を含む）におけるデバイス拡張の挙動やデータの整合性維持メカニズムには、驚くほど大きな違いがあります。
本記事では、エンジニアがストレージ選定の際に直面する「ストライプ幅の動的変更」「リバランスの要件」「ライトホール問題」「スナップショット存在下での再配置リスク」という4つの技術的観点から、両ファイルシステムを徹底比較します。
1. 書き込み時の「動的ストライプ制御」：柔軟性か、構造的解決か
BtrfsとZFSの最も顕著な違いは、物理ディスクを論理空間へ抽象化する手法にあります。
Btrfs：チャンク・ベースの柔軟な割り当てBtrfsは物理デバイスを直接管理し、「チャンク（Chunk）」と呼ばれる論理単位（データ用なら通常1GiB）を動的に確保します 。
- 挙動: RAID5プロファイルを使用している場合、チャンク作成時にその時点で利用可能なディスク数に基づいてストライプ幅が決定されます 。
- RAID50の実態: Btrfsに「RAID50」という固有プロファイルはありませんが、複数のRAID5チャンクがプール内に混在し、並列的にI/Oが行われる状態は、実質的にRAID50と同等です 。
- メリット: サイズの異なるディスクが混在していても、利用可能なデバイスを組み合わせて最適なストライプ幅のチャンクを次々と作成できるため、物理容量を極限まで使い切ることができます 。
この辺りの情報は、ここから来ています。https://forum.rockstor.com/t/multi-device-btrfs-filesystem-with-disk-of-different-size/5976
ZFS：可変ストライプ幅（Variable Stripe Width）による最適化
対照的に、ZFSのRAID-Zは、書き込みトランザクションごとにストライプ幅を動的に決定する手法を採っています 。
- 挙動: 書き込むデータのサイズに合わせてパリティを計算し、常に「フルストライプ・ライト」として処理します 。※データサイズに合わせたストライプ幅になる。という意味です。物理デバイスなどからくるストライプ幅ではありません。この結果、パリティ部分をデータにまたがって共有することが無くなるため、後述のメリットが出てきます。
- メリット: 伝統的なRAID5で発生する「一部のデータだけを書き換えるための読み込み・更新・書き戻し（RMW）」プロセスが不要になり、パフォーマンスと信頼性が飛躍的に向上します 。
2. デバイス追加時の挙動：Balanceか、Reflowか
容量が不足してディスクを追加した際、既存データの再配置が必要かどうかは運用コストに直結します。
Btrfs：balance 操作の必然性
Btrfsにデバイスを追加しても、既存のデータは自動的に移動しません 。
- 仕様: 新しいディスクを含む「より広いストライプ幅」の恩恵を受けるには、btrfs balance を実行する必要があります 。
- 運用の痛み: Balanceは全データの読み書きを伴う重厚な処理であり、数TBの再配置には数日を要し、システムへのI/O負荷も増大します 。しかし、このプロセスを経て初めて、データロケーションの最適化とRAIDレベルのオンライン変換が完了します 。
この辺りですね。https://btrfs.readthedocs.io/en/latest/Balance.html
範囲を絞らないと、馬鹿みたいに時間かかるよ。と
ZFS：RAID-Z Expansionと「Reflow」
ZFSでは、新しいデバイス(正確にはVDEV)を追加した際に既存データを強制的に書き換える（Rewrite）必要はありません。SPA（Storage Pool Allocator）が空き容量の多い新しいデバイスを優先的に利用し、時間の経過とともに負荷を平準化します 。
- 最新機能: 近年導入された「RAID-Z Expansion」では、既存データの論理的なストライプ比率を維持したまま物理配置を調整する「Reflow（再フロー）」という洗練された手法が採用されています 。
- 一貫性: 既存のブロックポインタを変更せずに再配置を行うため、Btrfsのリバランスよりもはるかに軽量かつ安全です 。
※reflowは、VDEVを構成するRAIDにディスクを追加した場合に、VDEV内の全データを新しいディスク枚数に合わせて物理的に並べ直す処理です。rewriteは、VDEVを追加した場合に、各VDEV間で使用量を平準化するために実行する処理です。
3. 「RAID書き込みホール（Write Hole）」問題へのアプローチ
電源喪失時にデータとパリティの不整合が発生する「ライトホール」は、ソフトウェアRAIDの宿命的な課題です。
ZFS：構造的な克服
ZFSは前述の「可変ストライプ幅」とCoWを組み合わせることで、この問題を根源的に解決しています 。書き込みが完全に完了し、メタデータのポインタが更新されるまで古いデータは残るため、どの瞬間にクラッシュしても不整合な状態は発生しません 。
Btrfs：Kernel 6.2以降の改善と現状
BtrfsのRAID5/6は長らくこの問題を抱えており、開発側も「実験的」としてきましたが、Linux Kernel 6.2（2023年）で重大な修正が入りました 。
※このあたりですね。https://btrfs.readthedocs.io/en/latest/Kernel-by-version.html
- 改善点: パリティ更新前にストライプ全体のチェックサムを確認する「フルRMWサイクル」を導入し、不整合の発生を防ぐ仕組みが取り入れられました 。
- 展望: 現在開発中の「Raid Stripe Tree (RST)」により、エクステントごとに物理配置を管理する新しいツリー構造が導入され、将来的にライトホール問題は完全に解消される見込みです 。
4. スナップショット存在下でのデータ再配置リスク
「CoWだから再配置は安全」という言説には注意が必要です。特にBtrfsのスナップショット運用においては、複雑な課題が潜んでいます。
Btrfs：リロケーションの複雑さとデータ消失リスク
Btrfsでリバランスを行う際、移動対象のエクステントを参照している全てのメタデータ（スナップショット）を更新する必要があります 。
- 技術的課題: スナップショットが多数存在する場合、更新の連鎖によって「遅延参照（delayed refs）」が爆発的に増加し、パフォーマンスが極端に低下する「delayed ref explosion」が発生します 。
- 過去のリスク: リロケーション中に世代番号の不整合が起き、ファイルシステムがマウント不能になるバグ（parent transid verify failed）が報告されたこともあります 。スナップショットが多い環境でのリバランスは、理論的・経験的にリスクを伴う操作であると認識すべきです 。
この辺りで議論されていたみたいです。現在は修正済み？https://github.com/btrfs/btrfs-todo/issues/54
ZFS：不変のブロックポインタによる堅牢性
ZFSのスナップショットは作成された時点でそのブロックポインタが「不変（Immutable）」となります 。
- 仕様: RAID-Z拡張のReflowプロセスは、RAID層での物理配置調整とファイルシステム層の管理が分離されているため、スナップショットが数千個あってもメタデータの整合性を脅かすことはありません 。
まとめ：アーキテクチャ選択の指針
これまでの分析から、ユースケースに応じた最適な選択が見えてきます。
結論
- Btrfs は、柔軟なディスク管理とLinuxカーネルへの深い統合を求める場合に最適です。RAID5/6構成を組む際は、最新のメインラインカーネル（6.20以降推奨）を使用し、UPSを併用した上で、メタデータをRAID1C3で保護するハイブリッド構成が推奨されます 。※逆説的に、Btrfsを使用するシステム(NASなど)をやむを得ず導入する場合は、なるべく新しいカーネルバージョンを採用しているものを導入するとよいかと思います。
- OpenZFS は、大規模なデータ保護と長期的な信頼性を最優先する環境において、依然として他の追随を許さない優位性を持っています。
ストレージの進化は止まりません。BtrfsのRSTが正式に統合される日が来れば、この力学はまた変わるかもしれません。皆さんは、どちらの「未来」にデータを託しますか？
