BcachefsがLinuxカーネル本体から外れた理由｜DKMSモジュール化の経緯

BcachefsとLinuxカーネル統合への長い道のり

Bcachefsは、Linuxカーネルの著名なコントリビューターであるKent Overstreet氏が長年にわたって開発を続けてきたコピーオンライト（CoW）ファイルシステムです。ext4やXFSの枯れた安定性を持ちながら、Btrfsに比べてコードベースがよりシンプルであることを目指して設計されており、チェックサム・スナップショット・透過的圧縮・イレイジャーコードといった現代的な機能を備えています。

2015年ごろから開発が続けられてきたこのファイルシステムは、Linus Torvalds氏らコアメンテナーへの長い働きかけの末、2023年後半のマージウィンドウでLinuxカーネル6.7への採用が決定しました。2024年1月にリリースされた6.7は、BcachefsがDistro提供カーネルへの道を歩み始める歴史的なマイルストーンとして、多くのOSS開発者から注目を集めました。

カーネル6.7採用が持つ意味と当初の期待

メインライン採用の最大のメリットは、ディストリビューションが標準カーネルパッケージにBcachefsを含められるようになることです。それ以前はout-of-tree（外部ツリー）でのビルドが必要だったため、エンタープライズ環境での採用障壁は高く、主にテスト用途にとどまっていました。

6.7採用後、Fedora・ArchLinux・Gentooなど変化の速いディストリビューションでは、インストーラーやドキュメントでBcachefsへの言及が増え始めました。「Btrfsより軽量なCoWファイルシステム」という位置づけで、ホームサーバーや開発用ワークステーションを中心に試用が広がりつつありました。現場でも「次の世代のext4候補」として期待する声が聞かれた時期です。

統合後に噴出した品質問題と開発プロセスの摩擦

しかし、メインライン採用直後から問題が表面化し始めます。カーネル6.7〜6.9系にかけて、Bcachefsに起因するパニック・データ破損の可能性・リグレッションの報告がkernel bugzillaやlkmlに相次ぎました。特に深刻だったのは、特定のワークロード下でのジャーナルのリプレイ失敗や、マウント済みボリュームの整合性チェックが誤ったエラーを返すケースです。

コードレビューの場でも軋轢が生じました。Overstreet氏が通常のマージウィンドウ期間外にパッチを提出したり、レビュー中のコードを前提とした変更を次々と積み重ねたりする開発スタイルが、カーネルコミュニティの標準的なワークフローとしばしば衝突しました。レビュアーが「このパッチは別のパッチに依存しているが、そちらはまだマージされていない」と指摘するやり取りが繰り返されました。

並行して、他のサブシステムメンテナーからも懸念が上がっていました。Bcachefsが汎用的なVFS（仮想ファイルシステム）レイヤーとの境界を越えて内部APIに直接依存しようとするケースがあり、「ファイルシステム層のカプセル化を壊す可能性がある」という批判が複数のメンテナーから寄せられました。

Linus Torvaldsとの公開的な衝突が示したもの

こうした積み重なった問題への対応として、Linus Torvalds氏はlkml上で複数回にわたり率直な批判を行いました。特に2024年中盤の発言は広く引用されており、「マージウィンドウのルールは全員に適用される」「バグレポートを無視してはならない」といった内容で、特定のファイルシステムや開発者を名指しする形での注意喚起となりました。

このやり取りはBcachefsだけの問題にとどまらず、「out-of-treeで十分に成熟していないコードをメインラインに受け入れるべきか」というより広い議論を再び喚起しました。大規模な機能を持つファイルシステムのメインライン統合には、コードの完成度だけでなく、メンテナーがカーネルコミュニティの開発文化に沿って継続的に協調できるかどうかが問われる、という認識がコミュニティ内で改めて共有されることになりました。

Overstreet氏自身も、この時期に自身のブログやメーリングリストで状況を説明する投稿を行っています。「カーネルの複雑さが増す中でファイルシステムを安定させることの困難さ」を訴える内容でしたが、開発プロセス上の問題については一部でコミュニティとの認識にずれが残りました。

メインラインからの実質的な離脱とDKMSモジュール化の経緯

継続的なリグレッションと開発プロセス上の摩擦が解消されない状況の中、Bcachefsのカーネルツリー内での扱いは次第に変化していきます。一部のディストリビューションはBcachefsをデフォルト無効化あるいは「実験的」フラグ付きに格下げし、エンタープライズ向けの長期サポートカーネルでは採用を見送る判断が広がっていきました。

こうした流れを受けて、Bcachefsの開発はカーネルツリー本体から切り離し、DKMS（Dynamic Kernel Module Support）を通じた外部モジュールとして提供する方向へと移行することになりました。DKMSはDell社が主導して開発したフレームワークで、カーネルのアップデート時に外部モジュールを自動的に再コンパイルする仕組みです。ZFS on Linuxがこのモデルで長年安定して運用されてきた事例が、Bcachefsのモジュール化を現実的な選択肢として示していました。

モジュール化のメリットは、カーネルのリリースサイクルに縛られることなく、Bcachefs独自のペースでバグ修正や機能追加ができる点にあります。一方で、将来のカーネルバージョンとのABI互換性の維持は開発者側の責任となるため、メンテナンス負荷は増します。ZFS on Linuxがメジャーカーネルバージョンのたびにパッチ対応を迫られてきた歴史は、その現実を如実に物語っています。

現場の運用者が把握しておくべき現状と今後の見通し

2026年時点でBcachefsを既存環境で運用している、あるいは採用を検討している担当者にとって、この経緯が意味するのは次のような実務上の変化です。

• 標準カーネルパッケージへの同梱が保証されなくなる。ディストリビューションによっては追加パッケージのインストールとDKMSの設定が必要になります。
• カーネルアップデートのたびにモジュールの再ビルドが必要。DKMSが自動化していますが、ビルド失敗時のフォールバック手順をあらかじめ確認しておく必要があります。
• エンタープライズ向けサポートは依然として限定的。RHELやSLESのような商用ディストリビューションでの公式サポートは現時点では見込めない状況が続いています。

なお、BcachefsのDKMSモジュール自体は引き続き開発が続いており、主要なGitリポジトリからソースを取得してビルドすることは技術的に難しくありません。ホームラボやテスト環境での評価を続けている運用者も多く、ファイルシステムとしての技術的なポテンシャルに対する評価が下がったわけではありません。

今回の経緯が示す教訓は、OSS開発における「コードの品質」と「コミュニティとのプロセス適合性」の両立の難しさです。優れた技術的アイデアを持つプロジェクトであっても、大規模なコミュニティの文化的規範と長期的に折り合いをつけることができなければ、メインラインでの存続は難しくなります。ZFS on Linuxが示したように、out-of-treeのモデルが必ずしも失敗を意味するわけではなく、独自の成熟サイクルを持つことでかえって安定した運用が可能になるケースも存在します。Bcachefsがそのモデルを採用することで、どのような到達点を見せるかは、これからの開発動向を見守る必要があります。