LinuxでのO_DIRECTの使用

この質問がプログラマー指向すぎる場合は、お知らせください。Linux 2.6のopen（）システムコールのO_DIRECTフラグに精通している人がいるのだろうか？Linusはその使用を軽んじていますが、高性能ファイル書き込みはその使用を示しているようです。現実世界での経験と推奨事項を知りたいです。

詳細：私が使用しているアプリケーションは独自のキャッシュを維持しており、その際に平均で5倍以上の高速化を実現しています。ファイルに書き込むとき、キャッシュの内容はファイルシステムのキャッシュに書き出される必要がありますが、これは冗長であり、パフォーマンスの問題と思われます。

OK、あなたは経験を求めます、これは質問を少し主観的で議論的なものにしますが、まずまずです。

Linusは、人々が通常O_DIRECTに帰属する用途について言及していること、そしてそれらの用途については、IMO Linusがほとんど正しいと述べました。直接I / Oを行う場合でも、デバイスとの間でデータを直接プログラムステートメントに転送することはできません。（プログラムまたはデバイスによって）いっぱいになり、システムコールを介して相手側に転送されるバッファが必要です。また、それを効率的にするために、再び必要になったときのために、今読んだばかりのものを読み直したくないでしょう。そのため、何らかのキャッシュが必要になります...まさに、ページキャッシュであるO_DIRECTなしでカーネルが提供するものです！なぜそれを使用しないのですか？また、より多くのプロセスが同じファイルに同時にアクセスしたい場合にも利点があります。O_DIRECTを使用すると災害になります。

そうは言っても、O_DIRECTには次の用途があります。何らかの理由でブロックデバイスから直接データを取得する必要がある場合。パフォーマンスとは関係ありません。

パフォーマンスのためにO_DIRECTを使用する人は、通常、不正なページキャッシュアルゴリズムを備えたシステム、POSIXアドバイスメカニズムを持たないシステム、または他の人が言ったことを不注意に繰り返す人です。これらの問題を回避するために、O_DIRECTがソリューションでした。Linux（OTOH）には、実際の根本的な問題を修正するという哲学があります。根本的な問題は、ページキャッシングで悪い仕事をしたOSでした。

catの簡単な実装にO_DIRECTを使用して、マシンのメモリエラーを見つけました。これは、O_DIRECTの有効な使用方法の1つです。それはパフォーマンスとは何の関係もありませんでした。

実際にO_DIRECT は、次のいずれかを避けるために必要です

• キャッシュ汚染 -オーバーヘッドに意味がないことを知っている場合があります。たとえば、非常に大きなファイルを扱う場合、たとえば64 GiBのRAMが2 GiBしかない場合などです。ユーザーが検証することを決定した32 GiBのTorrentファイルは、キャッシュの適切な候補ではないようです。それは、独自のオーバーヘッドを持つ単なる追加のアクティビティです。そして、いくつかの本当に有用なデータがキャッシュから削除される可能性があります。
• ダブルキャッシュ —たとえば、一部のRDBMS（MySQLを参照）では、独自のキャッシュを定義できます。データベースは、SQLのプランニングなどを知らないカーネルの仮想メモリよりも、キャッシュの方法と内容をよく知っているはずです。

—どうやら、これはダメです。またO_DIRECT、高速になることを意味するものではなく、多くの場合そうではありません。

O_DIRECT新しいファイルシステムを使用した新しいカーネルでは、使用が失敗する可能性があることに注意してください。たとえば、このバグレポートを参照してください。そのため、使用がしばしば疑わしいだけでなく、次世代のLinuxディストリビューションではまったく機能しない可能性があります。そのため、たまたまあなたがそれが利益をもたらすかもしれないことを証明することができたとしても、私はその上で私のコードのパフォーマンスに賭けません。

パフォーマンスに関係があります。

興味深い例は、mmapエンジンを使用したmongodbです。O_DIRECTは、他の人が述べているように、データがしばらく読み取られそうにない場合に最適です。mongodbでは、データベースジャーナルはO_DIRECTを使用して書き込まれますが、データとインデックスの書き込みはページキャッシュメカニズム（pdflush）によって処理されます。予期しない停止（カーネルパニック、ディスクまたは電源障害）。O_DIRECT書き込みが不揮発性ストレージにコミットされる前にバッファリングが残っていることに注意してください。これにより、データ損失が減少します。

O_DIRECTのもう1つの重要な機能は、書き込みシーケンスをより詳細に制御できることです。この場合も、書き込みの順序は保証されません（不揮発性のキャッシュディスクコントローラーがあり、fifoスケジューラを使用している場合を除き、これらには独自の複雑さがあります）。したがって、mysqlはジャーナリングだけでなくデータ/インデックスにもO_DIRECTを使用しますが、通常は後者が最初にコミットされると予想できます。

ただし、O_DIRECTはリソース割り当ての公平性を損なうことに注意してください。アプリケーションが高速化される理由の1つは、他の処理が遅くなることです。

@Julianoがすでに言ったことに関連して。

チェックアウトposix_fadvise本当の問題は、不正行為、ファイルシステムのキャッシュアルゴリズムの基礎となるのであれば、あなたはどのようにファイルシステムを使用しようとしている、それに助言を与える試すことができます。うまく実装されたfsでは、パフォーマンスが向上します。（同様の考慮事項に触れる別のトピックへのリンク/programming//a/3755818/544721）