ＨＯＭＥ ＞ リナックスマスター.JP 公式ブログ ＞ Linux情報・技術・セキュリティ ＞ Btrfs Direct I/Oがカーネル修正で約59%高速化｜SB_NOSEC抜けによる直列化を読み解く
この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
そう要約できる修正が、Btrfs に入ろうとしています。Direct I/O の書き込みスループットが、ベンチマーク条件によっては約59%、数値で言えば826 MB/s から1311 MB/s へ跳ね上がる。原因は新機能でもチューニングでもなく、2023年のmount API移行のときに設定が抜け落ちていた1つのフラグでした。
派手な新機能ではありませんが、現役のサーバー管理者にとっては「自分の環境のI/O性能が、ある日アップデートで素直に速くなる」話です。なぜ遅かったのか、どんなワークロードが恩恵を受けるのか、自分のサーバーは関係するのかを、落ち着いて整理します。
「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P／登録10秒／解除も3秒 ／
詳細はこちら
何が変わったのか——Direct I/O書き込みが約59%高速化
要点を先に書きます。・Btrfs の Direct I/O 書き込みスループットが、あるベンチマークで826 MB/s → 1311 MB/s に向上した
・改善幅は約59%（ほぼ60%）。Intel の Kernel Test Robot による別計測では約12%の改善も報告されている
・修正は実質ワンライン。新機能の追加ではなく、抜けていた設定を元に戻すだけの変更
公式情報の整理は以下のとおりです。
・対象: Btrfs の Direct I/O 書き込み（同一ファイルへの並行書き込み）
・性能改善: 826 MB/s → 1311 MB/s（約59%向上、特定のFIOベンチマーク条件下）
・別計測: Intel Kernel Test Robot で約12%改善
・取り込み先: 「-next」ツリーに入り、Linux 7.2 のマージウィンドウ（6月）で取り込まれる見込み
ここで強調しておきたいのは、この59%という数字は特定のベンチマーク条件で出た値だ、という点です。すべてのワークロードで6割速くなるわけではありません。効くのは「Direct I/O を使い、同じファイルに複数スレッドから並行して書き込む」場面です。後述しますが、これはデータベースや一部の仮想化ストレージで現れやすいパターンです。自分のワークロードがそこに当たるかどうかで、体感は大きく変わります。
なぜ遅かったのか——SB_NOSECフラグの抜け落ち
ここは技術的な話です。読まなくても運用は回せますが、「なぜ1行で60%も変わるのか」を理解しておくと、似たクラスの性能劣化が出たときに早く疑えます。鍵になるのは SB_NOSEC というスーパーブロックのフラグです。これは VFS（仮想ファイルシステム層）に対して「このファイルシステムには、セキュリティ用の拡張属性（xattr）を持たないファイルがあり得る」と伝えるものです。このフラグが立っていると、VFS は書き込みのたびに毎回セキュリティ属性をチェックする処理を省ける、という最適化が効きます。
問題は、Btrfs が2023年に新しい mount API へ移行したときに、この SB_NOSEC を設定する処理が抜け落ちていたことです。結果として、Btrfs の inode に対する IS_NOSEC のチェックが常に false を返すようになっていました。
これが Direct I/O の書き込みパスに効いてきます。SB_NOSEC が立っていないと、btrfs_direct_write() は inode ロックを「排他（exclusive）」で取得します。排他ロックを取るということは、同じファイルへの Direct I/O 書き込みが、複数スレッドから来ても1つずつ順番に処理される（直列化される）ということです。本来なら並行して走れる書き込みが、ロック待ちで列を作っていたわけです。
修正は、この SB_NOSEC フラグを正しく設定し直すだけ。たったそれだけで、排他ロックが不要になり、同一ファイルへの並行 Direct I/O 書き込みが直列化から解放され、スループットが跳ね上がりました。「機能のバグ」ではなく「移行時の設定漏れ」だったため、長く気づかれにくかったのだと思います。
PR / ファイルシステムとI/Oの仕組みを腹落ちさせたい方へ
［試して理解］Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】
ストレージ階層・ファイルシステム・キャッシュとDirect I/Oの違いを、手を動かす実験と図解で押さえられる一冊です。今回のような「ロックで直列化されていた」話を自分で再現・確認する土台になります。
自分のサーバーは関係するのか
恩恵を受けるかどうかは、次の2点で切り分けられます。・ルートやデータ領域に Btrfs を使っているか
・そのうえで Direct I/O を使い、同一ファイルへ並行書き込みするワークロードがあるか
自分の環境で Btrfs を使っているかは、次で確認できます。
・mount | grep btrfs
・df -T で TYPE 列に btrfs があるか
そのうえで「Direct I/O かつ同一ファイル並行書き込み」に当たりやすいのは、次のようなケースです。
・データベース（O_DIRECT でデータファイルに書き込む構成）
・一部の仮想マシンのディスクイメージ（cache=none 相当でホスト側キャッシュをバイパスする構成）
・大きな1ファイルへ複数スレッドで並行追記・更新するアプリケーション
逆に、通常のファイルコピーや、バッファ I/O（ページキャッシュ経由）が中心の用途では、この修正の影響はほとんど出ません。Web サーバーの静的配信や一般的なログ出力なら、体感はまず変わらないと考えてよいです。
自分のワークロードが Direct I/O を使っているかどうかは、アプリ側の設定で判断します。PostgreSQL や MySQL なら O_DIRECT 系のオプション（例: innodb_flush_method=O_DIRECT）が有効か、KVM/QEMU なら仮想ディスクの cache 設定が none かどうかを確認してください。これらが有効で、かつ下回りが Btrfs なら、今回の修正の射程に入ります。あとで効果を測れるよう、現状のディスク構成（lsblk と df -T）を控えておくと比較がしやすくなります。
なお、同じく Direct I/O が中心でも、別々のファイルへ書き込むワークロードでは今回の直列化は起きにくいです。「同一ファイルに複数スレッドから並行書き込み」という条件が肝なので、自分のアプリがどのI/Oパターンかを一度整理しておくと、過度な期待も過度な不安も避けられます。
私の感覚では、この修正がいちばん効くのは「Btrfs の上でデータベースや VM を O_DIRECT で動かしている」中規模以下の環境です。ext4 や xfs を選んでいた現場には直接は関係しませんが、Btrfs のスナップショットや圧縮を目的に採用していて、かつ Direct I/O 系のワークロードを載せているなら、Linux 7.2 系のカーネルが降りてきたタイミングで素直に効いてきます。ストレージのマウント状況の確認方法はLinuxでマウント状況を確認するコマンドに整理してあるので、あわせて自分の環境を棚卸ししてください。
管理者として何をすべきか
今すぐ手を動かす種類の話ではありません。脆弱性ではないので、緊急のパッチ適用は不要です。とはいえ、放置でよいわけでもありません。次の順で備えるのが現実的です。・棚卸し: 自分のサーバーで Btrfs を使っている領域と、その上の Direct I/O ワークロードを把握しておく（mount / df -T / アプリの I/O 設定）
・計測: 性能に敏感な用途があるなら、現状の Direct I/O 書き込みスループットを fio などで一度測っておく。あとで「本当に速くなったか」を比較できる。たとえば Btrfs 上の作業ディレクトリで fio --name=diotest --filename=./diotest --direct=1 --rw=write --bs=1M --size=2G --numjobs=4 --group_reporting のように、同一ファイルへ複数ジョブで Direct I/O 書き込みを走らせ、WRITE のスループットを控えておく（テスト後はファイルを削除する）
・更新の追従: 利用ディストロが Linux 7.2 系のカーネル、または当該修正をバックポートした版を出したら、検証機で先に確認してから本番へ反映する
・効果確認: 適用後に再計測し、自分のワークロードで効果が出たかを数字で確認する
「カーネルを上げたら勝手に速くなっていた」で済ませず、変更の前後を数字で押さえておくと、次に性能劣化や改善が起きたときに原因を切り分けやすくなります。今回のように「設定漏れで3年間遅かった」事例は、計測の習慣がなければ気づきようがありません。
PR / コマンドの基礎から固め直したい方へ
mount・df といった確認系コマンドを「読む」だけでなく「打てる」ようにしておくと、今回のような棚卸しを自分の手で回せます。コマンドラインの基礎を一冊で固め直すのに向いています。
現場の教訓——「速くなった」も計測で裏を取る
今回いちばん示唆的だったのは、性能劣化の原因が「機能のバグ」ではなく「移行時にフラグを1つ立て忘れた」という、ごく地味な見落としだった点です。しかも3年近く誰も気づかなかった。新機能のバグは目立ちますが、こうした「静かな性能劣化」は、計測の習慣がない現場では見えないまま放置されます。だからこそ、管理者にできる現実的な備えは「変化を数字で押さえる」に尽きます。脆弱性が出たら確認・緩和、性能の話が出たら計測・比較。記事を読んで終わりにせず、自分の検証機で fio を回し、mount のフラグを確認し、前後を比べる。この地味な習慣が、「設定漏れで遅かった」「アップデートで速くなった」のどちらも、確かな手応えとして自分のものにしてくれます。
「なんとなく動いている運用」から数字で語れる運用へ
mount のフラグ、df -T、fio での計測。記事を読むだけでなく、検証機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報を集めるのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
暗記不要・1時間後にはサーバーが動く
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
Linux無料マニュアル（図解60P）
名前とメールで30秒登録
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：CIFSwitch（19年物のcifs.spnego特権昇格）でrootを取られる｜影響ディストロと緩和手順
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます