カーネルからの Bcachefs コードの削除: ファイルシステムの将来に何を意味するのか

Bcachefs は Linux 6.18 カーネルから削除され、117,000 行ものコードが削除されました。Linus Torvalds 氏のこの決定は、10 年にわたるパッチ、テスト、そして意見の相違の繰り返しの末に下されたものです。管理者にとっての疑問は単純明快です。外部モジュール方式を続けるか、従来の Ext4、XFS、ZFS に戻るか？ タイミングは決して軽視できません。DKMS パッケージは Debian、Fedora、Ubuntu のリポジトリに追加されたばかりで、生産性の高いユーザーはブラックマンデーを免れています。この削除がカーネルガバナンス、そしてさらに重要なファイルシステムの将来にどのような影響を与えるかは、まだ分かりません。 Linux 6.18 カーネルからの Bcachefs の突然の削除：真の理由 これはすべて、Kent Overstreet 氏とコアチームの間で、コーディングスタイルとコミュニケーションをめぐる対立に端を発しています。 Linus Torvalds 氏は 6.7 への統合を「様子を見る」程度に容認しましたが、6.17 以降の貢献は凍結しました。次のマージウィンドウでは、この判断が確定しました。つまり、完全に削除されたということです。公式の理由は、DKMS モジュールが準備できているため、「混乱を減らすため」です。非公式には、どんなに有望なプロジェクトであっても、共同作業のプロセスを無視することはできないという警告です。さらに、このカーネルは ISO イメージで 350 KB を節約します。これは、ミニマリストブートを今でも支持する人々への配慮です。 Red Hat、Canonical、および派生製品への即時的な影響 Red Hat は、RHEL から受け継いだ慎重な姿勢を優先し、Bcachefs をデフォルトで有効にしたことはありませんでした。 Canonical

は「Ubuntu Pro」インストーラーでこれを検討していましたが、ネイティブ暗号化には既に ZFS を採用していました。Fedora 側では、3 月以降、ナイトリースピンに Bcachefs が組み込まれていました。そのため、Fedora 40 では、現在の Debian Sid と同様に、DKMS モジュールに切り替わります。 リスクとは？カーネルアップグレード時に、本番サーバーでモジュールの再コンパイルを忘れてしまうことです。メンテナーは、バージョンをロックするか、再起動のたびにAnsibleを使って.koファイルの存在を確認することを推奨しています。これは、Nvidia 96xxドライバの時代以来、経験したことのないプロセスです。実証済みの代替手段：Ext4、XFS、ZFSが主流 StackShareの調査によると、2025年には、 Ext4は80%のサーバー導入でデフォルトの選択肢であり続けるでしょう。その堅牢性と低いCPUオーバーヘッドは、コンテナ化されたワークロードにおいて無敵です。 XFSは、その強力な連続割り当てにより、非常に大きなファイルを扱う導入で成功を収めています。ZFSは、CDDLライセンスによってメインラインへの統合が制限されているにもかかわらず、スナップショットとオンライン重複排除の利点を維持しています。Ryzen 9000の最近のベンチマークでは、シーケンシャルリードにおいてBcachefsと比較してわずか3%の差しか見られませんでした。これは、公式サポートの安心感と比較すると無視できるほどの差です。

DKMSモジュールとしてBcachefsに移行すべきでしょうか、それとも使い続けるべきでしょうか？

既にBcachefsを実行しているクラスターも、必ずしも安全とは限りません。 DKMS モジュールは vCPU 上で 40 秒でコンパイルされ、互換性はカーネル 5.15 LTS まで遡ります。しかし、メジャーアップグレードのたびに、復元テスト、RAID 再構築、チェックサム検証といった手動チェックポイントが必要になります。

小規模なチームにとっては、Ext4 に戻りたいという誘惑は強いでしょう。しかし、CoW とチェックサムを放棄すると、増幅書き込みと SSD の摩耗が増加します。妥当な妥協案は、重要なボリュームを ZFS に変換し、LZ4 圧縮の威力が依然として発揮される一時的なオブジェクトキャッシュには Bcachefs を維持することです。

この物語は、Linux カーネルの文化を露呈しています。

30 年間、カーネルは 9 秒ごとにパッチがリリースされるペースで進化してきました。Linus Torvalds は私たちに、あらゆるコードに門戸は開かれているものの、議論は公開され、時には白熱することを思い出させてくれました。Bcachefs はこの自然淘汰を経験した最初でも最後でもありません。Reiser4 や Tux3 を思い出してください。 コミュニティはこの削除を明確なシグナルと捉えています。つまり、テストの数と質は設計の優秀さよりも優先されるということです。ストレージのバグバックログはすでに減少しているため、サブシステムのメンテナーはこれを歓迎しています。皮肉なことに、この削除をめぐる話題は、最初のコミットでは得られなかったBcachefsの注目度を高めています。 Bcachefsは再び復活するのでしょうか？ Kent Overstreet氏はまだ最後の言葉を残していません。彼はカーネルのスタイルとテスト規約に沿った「bcachefs-next」に取り組んでいます。彼がレビュー担当者のタスクフォースを結成できれば、6.20への扉が再び開かれる可能性があります。 その間、管理者はDKMSリリースに注目し続けるか、それとも3つの歴史的柱でボリュームを固めるかを選択する必要があります。1ミリ秒単位のI/Oが重要な世界では、この決定は軽々しく下されるものではありませんが、空きストレージを求める旅はパッチを次々とリリースしながら続いています。出典:

linuxnews.de