書き込み禁止がない場合、ディスクコントローラは同じセクタへの同時書き込みをどのように処理しますか？

Question

O_DIRECT | O_ASYNCでファイルを開き、その間にfsyncまたはfdatasyncを使用せずに、同じディスクセクタへの2つの同時書き込みを実行すると、Linuxディスクサブシステムまたはハードウェアディスクコントローラは、そのディスクの最終データセクターは2番目の書き込みになりますか？

O_DIRECTがOSバッファキャッシュをバイパスしている間は、データは最終的に低レベルIOキュー（ディスクスケジューラキュー、ディスクドライバのキュー、ハードウェアコントローラのキャッシュ/キューなど）で終了します。私はIOスタックをエレベータアルゴリズムまで追跡しました。例えば
要求の以下のシーケンスは、エレベーターのコードは、それぞれのバッファ1,2からsector1,2を合体する「バックマージ」を行うだろう

write sector 1 from buffer 1 
write sector 2 from buffer 2 
write sector 1 from buffer 3 [Its not buffer 1!!] 

ディスクスケジューラキューで終わる場合。そして、ディスク2つのディスクIOを発行します。しかし、ディスクセクタ1の最終データがバッファ1かバッファ3かどうかはわかりません（ドライバ/コントローラの書き換えセマンティクスについてはわかりません）。

シナリオ2：

write sector 1 from buffer 1 
write sector 500 from buffer 2 
write sector 1 from buffer 3 

どのようにこのシナリオが処理されるのでしょうか？ より基本的な質問は、AIOを使用してO_DIRECTモードで書き込みを行うときに、明示的な書き込み障壁がない場合、この一連の要求がディスクスケジューラのキューに入り込む可能性がありますか？
"はい"の場合、「同じセクタへの複数回の書き込みにより、最後の書き込みが最終書き込みになります」などの順序保証はありますか？
これは、ディスクコントローラ/そのキャッシュが、バリア内で書き込みを最適化してシーク時間を最適化するキャッシュに残っています。

Answer 1

障壁はgoing awayです。重複している書き込みの中で順序を指定する必要がある場合は、最初のものが完了するのを待ってから、2番目のものを発行する必要があります。 （障壁は消えています）

一般的なケースで私は保証がないと思います。最終的な結果は、タイミング、ホストとストレージデバイスの状態などによって、アプリケーションの観点から決定的ではありません。

リクエストキューは予測可能な方法でリクエストをマージしますが、ハードウェアは一貫した結果を提供する必要はありません同時にドライブのキューにある書き込みの場合

ストレージデバイスの速度やホストCPUの速度によっては、コマンドがストレージデバイスに送信される前に要求キューでマージが行われることを必ずしも保証できません。

残念ながら、O_DIRECTを使用しているアプリケーション（BIOSを直接構築するファイルシステムとは対照的に）は、完了を待つことになっていますが、私には分かりません。

Answer 2

OK、書き込みリクエストはリニアエレベータキューになります。この時点で、それらが異なるスレッドから来たものであるかどうかは関係ありません。同じ配列は、3つの連続した書き込みを発行する1つのスレッドの結果である可能性があります。さて、あなたはファイルをOSに、あるいは同じセクタへのシーケンシャル書き込みを何らかの形で並べ替えるコントローラに信頼していますか？私は間違っているかもしれませんが、もちろんです:)