write()システムコールを実行すると実際に何が起こりますか？
write()関数呼び出しを使用して特定のデータをファイルに書き込むプログラムがあるとします。現在、Cライブラリには独自の内部バッファがあり、OSにも独自のバッファがあります。
これらのバッファ間でどのような相互作用が発生しますか？
Cライブラリバッファが完全にいっぱいになると、OSバッファに書き込み、OSバッファが完全にいっぱいになると、実際の書き込みがファイルに対して実行されるようなものですか？
私はいくつかの詳細な答えを探しています、役に立つリンクも役に立ちます。UNIXシステムの場合はこの質問を検討してください。
私の知る限りでは...
このwrite()関数は、ライブラリがデータをバッファリングしない低レベルのものです（fwrite()ライブラリがデータをバッファリングする/バッファリングする可能性がある場所とは異なります）。
それにもかかわらず、唯一の保証は、次fsync()が完了する前にOSがデータをディスクドライブに転送することです。ただし、ハードディスクドライブには通常、OSの制御が及ばない独自の内部バッファがあるため、後続fsync()が完了した場合でも、データが実際にディスクドライブの内部バッファから書き込まれる前に、電源障害などが発生する可能性があります。ディスクの物理メディアに。
基本的に、データが実際にディスクの物理メディアに書き込まれていることを本当に確認する必要がある場合。次に、この要件を回避するためにコードを再設計するか、（小さな）障害のリスクを受け入れるか、ハードウェアがそれを実行できることを確認する必要があります（UPSを入手するなど）。
write（）システムコール（実際にはすべてのシステムコール）は、アプリケーションプログラムとOSの間の契約にすぎません。
現在、一部の（異常な）ファイルには、それらをサポートするためのwrite（）メソッドがありません。open（）が "/ dev / null"を実行し、それにバッファを書き込み（）することを想像してみてください。とにかく書き込まれることはないため、システムはバッファリングしないことを選択できます。
また、write（）の動作は、ファイルの性質に依存することに注意してください。ネットワークソケットの場合、write（fd、buff、size）は、サイズバイトが送信される前に返すことができます（writeは送信された文字数を返します）。しかし、一度送られたらどこにいるのかを知ることは不可能です。それらは、ネットワークバッファ（たとえば、Nagleを待機中...）、ネットワークインターフェイス内のバッファ、またはネットワーク上のどこかのルーターまたはスイッチのバッファにある可能性があります。
write()データをオペレーティングシステムに書き込み、すべてのプロセスで表示できるようにします（他のプロセスで読み取ることができるものである場合）。オペレーティングシステムがそれをどのようにバッファリングするか、またはディスクに永続的に書き込まれるとき、それは非常にライブラリ、OS、システム構成、およびファイルシステム固有です。ただし、sync()バッファを強制的にフラッシュするために使用できます。
隔離されているのは、POSIXでは、POSIX準拠のファイルシステムで、が返さread()れた後に発生することが証明できるファイルwrite()が、書き込まれたデータを返さなければならないことを要求しているということです。
UNIXを要求しているので、例として、ファイルが実際にマウントしたFTPサーバー上にある可能性があることに注意する必要があります。たとえば、ファイルはHDD上のファイルではありません/dev。/proc
また、Linuxでは、データはハードドライブに直接書き込まれません。代わりに、保留中のすべての書き込みを頻繁にフラッシュするポーリングプロセスがあります。
しかし、繰り返しになりますが、これらは実装の詳細であり、プログラムの観点からは実際には何の影響も及ぼしません。
OSに依存します。 man 2 sync（Linuxの場合）の説明を参照してくださいman 8 sync。
数年前、オペレーティングシステムは、ディスクへの書き込みをスケジュールするために「エレベータアルゴリズム」を実装することになっていた。アイデアは、ディスク書き込みヘッドの動きを最小限に抑えることです。これにより、同時にディスクにアクセスする複数のプロセスで良好なスループットが可能になります。