Bcachefs 1.38.6、「実験的」卒業後の実力をベンチマークで確認する
「実験的」の看板を外したBcachefs。その最初のリリースとなる1.38.6が、データベースやコンパイルといった実ワークロードでどれだけ前に進んだのか。独立したベンチマークが公開された。
200本のパッチが積み上げたもの
開発者のケント・オーバーストリート(Kent Overstreet)氏がBcachefs 1.38.6を「パフォーマンスリリース」と呼んだ。Bツリーのイテレータからトランザクションコミット、ジャーナル、ファイルシステムレベルのコードまで、200本以上のパッチを投入している。
変更の中身は地味だが効いている。ジャーナルのフラッシュパスは完全にロックフリーになった。Bツリーのシャーディングも手が入り、新規inodeの割り当てをCPUではなくPIDに基づかせ、ロック競合時にはスレッドをデータのシャードに対応するCPUへ移動させる。トランザクションコミットのホットパスが4KBのマシンコードにまで縮んだ。
ここで一つ、開発者が掘り当てた厄介な原因がある。GCCが static_branch_unlikely() を適切に処理できていなかった。Linuxカーネルにはランタイムパッチングで分岐コストをゼロにする仕組みがあるが、GCCはコールドパスの本体をキャッシュに優しい場所に配置してくれない。トレーシングやデバッグコードを無効にしていてもicacheを圧迫し、無視できない性能コストを生んでいた。デバッグコードは再び CONFIG_BCACHEFS_DEBUG の背後に戻された。
データベースでの手応え
Ryzen Threadripper 9980X(64コア/128スレッド、Zen 5)とSamsung 9100 PRO 1TB NVMe SSD、Ubuntu 25.10という環境で、Bcachefs 1.38.5と1.38.6が同一条件で比較された。
データベース系のワークロードは、全面的に1.38.6が上回った。
ClickHouseの1億行データセットで見ると、レイテンシの2回目実行は835 QPM対803 QPM、スループットで285対279。約4%の底上げだ。TigerBeetleはもっとはっきり出ている。4クライアント時のトランザクション処理は11万3,586 tx/s対10万8,432 tx/sと約5%伸び、p99レイテンシも727msに下がった(1.38.5は749ms)。16クライアントでも10万9,694 tx/s対10万3,546 tx/sと同じ傾向が続く。
PostgreSQL 18.1は差が小さい。250クライアントのRead/Writeで1万293 TPS対1万195 TPS、800クライアントでも1万1,137対1万1,055。レイテンシ改善は0.2〜0.5ms程度にとどまる。
| 1.38.5 | 1.38.6 | 変化 | |
|---|---|---|---|
| ClickHouse 1億行 | |||
| QPM | 803 | 835 | +4.0% |
| 処理量 | 279 | 285 | +2.2% |
| TigerBeetle | |||
| tx/s(4cl) | 10万8,432 | 11万3,586 | +4.8% |
| p99(4cl) | 749 ms | 727 ms | −2.9% |
| tx/s(16cl) | 10万3,546 | 10万9,694 | +5.9% |
| PostgreSQL 18.1 | |||
| TPS(250cl) | 1万195 | 1万293 | +1.0% |
| TPS(800cl) | 1万1,055 | 1万1,137 | +0.7% |
PostgreSQLはバッファプール内の処理が支配的で、ファイルシステムの違いが表面に出にくい。
コンパイルまで速くなった
ファイルシステムのバージョンアップでソフトウェアのビルドが速くなることは滅多にない。1.38.6では、Godotエンジン、Linuxカーネル(defconfigとallmodconfig)、LLVMのコンパイル時間が、いずれも短縮された。
コンパイルはファイルの書き込みと読み込みを繰り返す。そこでファイルシステムのトランザクション処理やロック競合がボトルネックになりうる。1.38.6のロック最適化とicache使用量の削減が、ビルド作業にまで波及した。SQLiteの書き込みベンチマークでも、1.38.6がわずかに速い。
合成I/Oテストには弱点も
一方で、FIOを使った合成I/Oテストでは結果がまだら模様になった。
シーケンシャルリードは全構成で1.38.6が大きく改善した。しかし4KBランダムリードはジョブ数によって優劣が分かれ、ランダムライトでは複数の構成で1.38.5を下回った。シーケンシャルライトもダイレクトI/O有効時に一部落ち込んでいる。
| ワークロード | バッファI/O | ダイレクトI/O |
|---|---|---|
| Randリード 4KB | △ | △ |
| Randライト 4KB | × | × |
| Seqリード 2MB | ○ | ○ |
| Seqライト 2MB | ○ | × |
オーバーストリート氏自身も、EPYC 9454でのfio 4Kランダムライトが70万IOPSと報告しており、XFSの100万IOPSに対してまだ差がある。コピーオンライト方式のファイルシステムは書き込みごとにデータチェックサムとBツリー更新を伴うため、既存のファイルにリマッピングするだけのXFSに対して原理的に不利だ。とはいえ、dbenchの48クライアントでは16.5 GB/sでXFSの16 GB/sを上回っており、リリースに含まれなかったパッチを加えると19 GB/sに達するという。
コピーオンライトファイルシステムが、汎用的な実ワークロードで従来型の最速ファイルシステムを超えるのは初めてだ
開発を追い続けてきたユーザーの言葉だ。数字の裏付けが、この評価を支えている。
「実験的」の看板が外れた意味
Bcachefsは2024年にLinux 6.7でカーネルに統合されたが、開発者とリーナス・トーバルズ氏の衝突を経て、2025年にカーネルツリーから外れた。現在はDKMSモジュールとして配布している。
オーバーストリート氏はPatreonの投稿で「数ヶ月前にウェブサイトからラベルを外した」と明かし、バグ報告の件数と深刻度が下がってきたことを根拠に挙げた。ただし、すべてのプロダクション環境に推奨できる段階ではない。ArchWikiも1.38.6のリリースノートを根拠に「安定」と記載を変更したものの、バックアップの重要性は引き続き強調している。
1.38.6は255デバイスのサポート、Reconcile(旧rebalance)機能の高速化と並列化、イレイジャーコーディングの安定運用も盛り込んだ。Ubuntu 26.04 LTS向けのパッケージがapt.bcachefs.orgから提供され、導入の敷居も下がった。
Rust化も進んでいる。ユーザースペースのコードはすでにRustに変換済みで、次のリリースではRustバインディングがDKMSモジュールに取り込まれる予定だ。
まだ途中だが、方向は定まった
合成I/Oテストの後退は、最適化がまだ特定のワークロードに偏っていることを示している。データベースやコンパイルといった複合的な処理では改善が明確で、ランダムI/Oの一部ではまだ詰めが足りない。
それでも、ベンチマークの数字が指し示すのは、コピーオンライトファイルシステムが「機能は豊富だが遅い」という評価から脱しつつあるという事実だ。XFSと正面から張り合える領域が生まれている。Linux 7.2のマージウィンドウ後には、BtrfsやEXT4、XFSとの横並び比較も予定されている。Btrfsはlarge foliosのデフォルト有効化がLinux 7.2でマージされたばかりで、ファイルシステムの勢力図が動く年になりそうだ。
参照元: Bcachefs 1.38.6 リリースノート(Kent Overstreet、Patreon)
他参照: Bcachefs 1.38.6 ベンチマーク(Phoronix)

関連記事
- Bcachefs 1.38.6、ジャーナルのロックを全面排除。性能に本腰
- Linux VFSが新ファイルシステムに「責任」を突きつける
- Linux 7.0リリース——Rust正式採用、AIが新常態へ
- Linux 7.0でPostgreSQL性能半減、修正困難か
- Rust製zlib実装がIntel CPUバグを回避。C言語なら黙って壊れていた
- Linuxカーネルが新ファイルシステムの受け入れ基準を明文化
- Linuxカーネル7.2、Rustで「書かなくて済むコード」がまた増える
- RustとAIで1からX11サーバーを書き直す。yserverが問いかけるもの
- RustベースOS「Redox OS」に5月の大型進捗、Xfce移植とファイルシステム高速化が同時到達
- Phoronix22周年が映すLinuxの22年間

