読み込みと書き込みは、あなたが思うほど対称ではない

Reading and writing are less symmetric than you (probably) think

readとwriteは一見対称に見えるが、バッファリングが絡むと挙動は大きく異なる。読み込みではエラーがfreadの戻り値より前に必ず表面化するのに対し、書き込みはバッファにコピーした時点で成功を返し、実際のwriteやエラー報告は後回しになる。さらにfsyncやcloseの戻り値、ディレクトリのfsyncまで確認しないと、データが本当に永続化されたかは保証されない。

書き込み側のバッファリングははるかに厄介だ。実際の書き込みとエラー報告を遅らせるが、ほとんどのプログラマはそれを知っているべきなのに、たいてい知らない。
  1. Pannoniae

    素晴らしい記事 :D 実はこのウサギの穴はもっと深い。読み込み側のバッファリングはほぼ常に良いが、読み込みは書き込みよりもはるかにレイテンシに敏感なことが多い。そのため、バッファサイズを増やしたりmmapで先読みを増やすと、追加のレイテンシのためにパフォーマンスが悪化するという逆説が生じる。また、バッファサイズを減らすと呼び出し回数が増えるため同じ効果が起こる。つまり、読み込みで最適なスループット/レイテンシ比を引き出すには、ワークロードごとにチューニングする必要がある…あるいは、いくつか異なるバッファサイズを試して、どれがよりうまく機能するかを見るだけでもいい。

    書き込みは逆で、通常はRAW(read-after-write)ではなく「ファイア・アンド・フォーゲット」なので、レイテンシはあまり気にしないが、書き込みが実際に到達するかどうかは非常に気にする…ここでもまた2つの競合するパラメータがある。書き込みをバッチ化すればするほど速くなるが、その分だけ書き込みが途中で壊れたりデータが失われる可能性が高まる。そして読み込みと違って、書き込みはアプリケーションレベルでは冪等ではないので、理想的にはクラッシュしても壊れないように、意味のある量のデータをアトミックに書き込むロジックが欲しい。

    実際にはほとんど誰もこんなことはやっていないが、楽しい思考実験だ :D

  2. 1317

    ああ、これは言語と脳の仕組みについての話かと思った。正直、その記事の方が面白そうだな、すみません

  3. vatsachak

    これはCPUキャッシュのレベルでも当てはまるので、おそらくずっと下まで波及するだろう。

    例えば、Jon GがJane Streetで講演して、謎のパフォーマンスバグが後にコア同士が同じキャッシュラインを奪い合っていたことに起因すると判明した話をしている

    https://youtu.be/tND-wBBZ8RY?is=624w3YoDN2QYBWuD

この日のほかの記事

2026-10-31