ダイレクトI/OとバッファドI/Oの設計判断

二つのI/O経路：何が違うのか

ファイルへの read/write には、カーネルのページキャッシュを経由する経路と、経由せずデバイスへ直結する経路の二つがあります。前者がバッファドI/O（通常の open の既定）、後者が O_DIRECT フラグで開いたときのダイレクトI/Oです。違いは「データがメモリ上のページキャッシュという中間バッファを通るかどうか」の一点に尽きます。

int fd1 = open("data", O_RDWR);              // バッファドI/O：ページキャッシュ経由
int fd2 = open("data", O_RDWR | O_DIRECT);   // ダイレクトI/O：キャッシュを迂回

バッファドI/Oでは、read はページキャッシュにヒットすればメモリから返り、write はキャッシュに書いて即座に返ります（ライトバック）。この透過キャッシュの挙動はページキャッシュとライトバックの仕組みが土台です。一方ダイレクトI/Oは、ユーザーバッファとストレージデバイスの間をカーネルのキャッシュを介さずDMAで直接やり取りします。

バッファドI/Oの利得と代償

ページキャッシュは「使われていない物理メモリを遊ばせず、ディスク内容で埋める」思想で動きます。これがもたらす利得は明確です。第一にホットデータのキャッシュで再読込がメモリヒットになる。第二に先読み（readahead）で連続アクセスを予測し先回りで取り込む。第三に書き込みの併合と遅延で、同じページへの連続更新を1回のI/Oにまとめ、write を即座に返す。

代償は二つです。一つは永続化の窓——write が返ってもデータはまだメモリ上のダーティページで、fsync を呼ぶまでクラッシュで失われ得ます（fsyncによるクラッシュ整合性）。もう一つが、本稿の主題に直結する余分なメモリコピーです。データは必ずページキャッシュを経由するため、ユーザーバッファ ⇄ ページキャッシュ の間でCPUコピーが1回挟まります。アプリが既に自前でデータをキャッシュしている場合、このコピーとカーネル側キャッシュは純粋な無駄になります。

なぜデータベースは独自バッファを持つのか

PostgreSQL の共有バッファ、MySQL/InnoDB のバッファプール、Oracle の SGA——主要なDBは例外なく自前のバッファプールをプロセス内に確保し、ページキャッシュとは別に管理します。理由は「アプリの方がカーネルより賢くキャッシュできる」からです。

決定的なのは回復可能性の制御です。DBはクラッシュ整合性のために、データページを書き換える前にWAL（先行書込ログ）を確実に永続化する、という順序を厳格に守る必要があります（Write-Ahead Logging）。汎用のページキャッシュは「どのページがログでどれがデータか」「どちらを先に書くべきか」を知らず、ダーティ閾値とタイマで勝手な順序で書き戻します。DBは自分のバッファを持ち、flushの順序とタイミングをアプリが完全に握ることで、回復可能な状態を保証します。さらに、どのページがホットかはクエリの意味を知るDB自身が最も正確に判断でき、汎用LRUより的確な置換ができます。

二重バッファリング問題

ここで問題が起きます。DBが自前バッファを持ったままバッファドI/Oでファイルを読むと、同じデータがページキャッシュとバッファプールの両方に載ります。これが二重バッファリング（double buffering）です。

バッファドI/O + 自前バッファプール（二重キャッシュ）:

  ストレージ ──DMA──► ページキャッシュ ──CPUコピー──► バッファプール ──► クエリ実行
                       （カーネルが保持）              （DBが保持）
                              ▲                            ▲
                      同じ8KBページが二箇所のメモリを占有・コピー1回分の浪費

弊害は二つ。メモリの二重消費——限られたRAMの一部をカーネルが重複して抱え、バッファプールに回せる分が減る。余分なコピー——ストレージ→ページキャッシュ→バッファプール でCPUコピーが1回挟まり、帯域とCPUを食う。DBにとってページキャッシュは「自分の方が上手にやれる仕事を、勝手に下手にやり直す邪魔者」になりがちです。

回避策：O_DIRECT とキャッシュ抑制

二重バッファリングの最も直接的な解が O_DIRECT です。ページキャッシュ層を外し、バッファプール ⇄ デバイス をDMAで直結するので、カーネル側の重複キャッシュと余分なコピーが消えます。DBはキャッシュ管理を一手に握れます。ただし O_DIRECT には厳しい整列制約があり、I/Oのオフセット・長さ・ユーザーバッファのアドレスをいずれもデバイスの論理ブロックサイズ（典型512Bや4KB）の倍数に揃える必要があります。整列していないと EINVAL で失敗します。

void *buf;
posix_memalign(&buf, 4096, 4096);            // バッファを4KB境界に整列
int fd = open("data", O_RDWR | O_DIRECT);
pread(fd, buf, 4096, 0);                      // オフセット・長さも4KB倍数

もう一つの軸は、バッファドI/Oのままキャッシュの保持を抑制する助言です。posix_fadvise でアクセスパターンをカーネルに伝えたり、読んだ直後に POSIX_FADV_DONTNEED で該当範囲のキャッシュ破棄を促せます。madvise(MADV_DONTNEED) も同系統です。これらは強制ではなく助言ですが、走査後のキャッシュ汚染を抑える軽量な手段になります。

設計判断のまとめ

要点は「キャッシュの主導権を誰が握るか」です。アクセスパターンや回復順序をアプリが正確に知っているなら（DBがその典型）、O_DIRECT でカーネルのキャッシュを外し、自前バッファで賢く管理する方が速く確実です。逆にアプリが特別な知識を持たない一般用途では、ページキャッシュに任せる方が先読みと併合の恩恵を素直に得られます。判断軸は、アプリのキャッシュ知識の有無・二重バッファリングの損得・整列と永続化の運用コストの三つです。この経路の先で、デバイスまでのI/O経路の最適化はストレージのキャッシュ階層、コピー自体を削る技法はゼロコピーI/Oの技法へ繋がります。