「デバイスでのWindows書き込みキャッシュバッファーフラッシュをオフにする」の機能と効果は何ですか

Windows 7では、デバイスマネージャーを使用してディスクのプロパティを表示し、[ポリシー]タブに移動すると、2つのスイッチ項目があります。書き込みキャッシュ。この質問ではありません。

そして

[X]デバイスでのWindows書き込みキャッシュバッファーフラッシュをオフにします <---これのみ！

Microsoftは、そのアイテムのタブに免責事項を記載しています。「データの損失を防ぐために、デバイスに別の電源があり、電源が失われた場合にデバイスがバッファをフラッシュできるようにしない限り、このチェックボックスを選択しないでください。」

簡単に言えば、ファイルの書き込み、ファイルの保存、ファイルのコピーについて、これは何を変更しますか？

1.偏執的なプログラムの書き込みアクションの変更：（ 事実またはフィクション）
キャッシュフラッシュを強制するプログラムの書き込みフラッシュの動作方法を変更しますか？一部のプログラムは、推測なしに書き込みを終了することを非常に意図していますが、これらのプログラムは保護的な書き込みを継続できますか、またはこれらのプログラムでもこの変更が行われますか？

2.影響
を受けるプログラムの種類：変更によって影響を受けるまたは受けないアクション/プログラムの種類は何ですか？タイプ、一部のプログラムストリーム、クイックアウトを行うもの、連続的なもの、保護的なもの（または簡単な用語で定義できる他のタイプ）。

3.何か、またはベンチマークさえ見ましたか：
設定がオンの場合、書面で目に見える変化は何ですか？観察された動作の変化の緩やかな例。または行動に変化が見られない？

4.ホールドアップまたは遅延とは何ですか：
これらのアクションのほとんどは、ほとんどのコンピューターで非常に高速であることがわかっています。データは最終的に書き込まれます。ドライブの速度と比較して、時間の量は重要ですか？

私の質問の目的のために、存在するリスクは質問の1つではありません。それをカバーしたい場合、邪魔になりません。

「Write cache buffer flushing」とはどういう意味ですか？このリンクはほとんど重複していますが、リンクは別のOS用です。Aにはいくつかの情報がありますが、リンクで使用されている用語も同じではありません。また、ここで概要を説明しようとした、ユーザーが知りたいと思う最も重要なことにも答えていません。

1. 最初の質問でのあなたの主張はフィクションです。Windows APIは、このような呼び出しをします、まだデータも無効にフラッシュするバッファの書き込みと、物理的なメディアにすべての方法を取得することを確認してください。そのため、「安全」で、プログラムが何をしているのかを知っているプログラムは問題ありません。などの呼び出し、最終的に、このAPIを呼び出すなど、.NETインチFlushFileBuffers() FileStream.Flush()

2. FlushFileBuffers()直接呼び出すことなく大量のディスクI / Oを実行するプログラム、または最終的にそれを呼び出すヘルパーAPIで、最も顕著なパフォーマンスの向上が見られます。たとえば、BOINCなどのデータが失われても大丈夫な非必須I / Oを実行している場合（失われた場合は、ファイルを再ダウンロードするか、計算を再計算するだけです）、呼び出しを回避できますFlushFileBuffers()、APIを呼び出すだけです。WriteFile()データはバッファリングされて書き込まれますが、実際にはファイル記述子が閉じられたときやプログラムが終了したときなど、潜在的に長時間書き込まれません。残念ながら、システムがクラッシュした場合（BSODなど）、すべてのデータが失われる可能性があるため、非常に重要ですバッファフラッシュが有効であるかどうかに関係なく、 call を行う貴重な/交換不可能なデータを扱う場合はFlushFileBuffers()、そうしないと、単純なドライバーのバグ（たとえば、グラフィックドライバーのバグ）により、大量のデータが失われる可能性があります。

3. ベンチマークは見つかりませんが、上記の2番目の項目の説明に適合するプログラムを使用すると、より多くのベンチマークに気付くでしょう。

4. 特にタイトなループで頻繁に行われる場合、ディスクへのデータの同期は実際にはそれほど高速ではありません。デフォルトでは、Windows Internalsの書籍を読んで正しくリコールした場合、NTFSはデフォルトですべてのダーティーファイルシステムバッファーを5秒ごとにディスクに同期します。これは明らかに安定性とパフォーマンスの適切なトレードオフです。頻繁にデータを同期する際の問題は、ハードドライブが多くのシークと書き込みを行うことです。

次の擬似コードを検討してください。

1: seek to a certain block (1)
2: write a couple megabytes of data into blocks starting at (1)
3: wait 2 seconds
4: seek to another block (2)
5: write some more megabytes of data into blocks starting at (2)
6: seek back to block (1)
7: write some more megabytes of data into blocks starting at (1)
8: wait 10 minutes
9: seek to block (1)
10: write some megabytes of data into blocks starting at (1)
11: wait 5 seconds
12: seek to block (2)
13: write some megabytes of data into blocks starting at (2)
14: explicit call to FlushFileBuffers()

5秒の自動バッファフラッシュをオンにした場合：

• 2行目、5行目、および7行目に発生する書き込みはRAMで発生し、最初の書き込みから5秒経過するまでディスクは移動しません。その後、最新のデータ（7行目）がブロック（1）に書き込まれ、ブロック（2）に書き込まれたデータのみが書き込まれます。
• ブロック10（1）および（2）のデータを上書きする行10および13で発生する書き込みは、再びディスクに書き込まれる必要があります。
• ブロック（1）が書き込まれてしまった回数の合計数ようにRAMには 3、であり、ディスクに、2ブロック（2）が書き込まれてしまった回数の合計数RAMには 2であり、そしてディスクに、2。

自動5秒バッファーフラッシュオフ（質問のチェックボックスの効果）：

• 行2、5、7、10、および13で発生する書き込みはRAMで発生し、行14が実行されるまでディスクは移動せず、その後、最新のデータ（行10および13から）がブロックに書き込まれます（1） （2）。2行目、5行目、および7行目の古いデータがハードディスクにヒットすることはありません！

ビジーなシステムでは、1秒あたり数十から数万のファイルへの書き込みが発生する可能性があることを考えると、これは、特に従来の回転ハードドライブ（SSDではあまり印象的ではありません）でパフォーマンスに優れています。RAMは一般的な尺度としてハードドライブより20倍高速ですが、SSDの場合はそのギャップは小さくなります。

彼らはあなたがバッテリー・バックアップを使用する必要があると言う理由はあなたのプログラマは怠け者だったと呼んでいなかったという理由だけで、ディスクに書き込まれていないRAMにバッファに書き込まれたデータの35分の価値を持ってしたくないということでFlushFileBuffers()、その後、持っています電源障害。もちろん、バッテリーのバックアップは、BSODを引き起こすドライバーのバグからあなたを保護しません...。

ChatBot John Cavilの回答をサポートするために、私は小さなテストプログラムを作成しました。

// ...
byteEx btTest;
btTest.resize(1024*1024, 0xff); // 1MB data

CSysFile sfTest(byT("test.bin"));

swTest.Start(); // Begin timing by call `QueryPerformanceCounter` API
for (UINT i=0; i<10000; ++i) // Write 1MB data for 10000 times
{
    sfTest.SeekBegin();
    sfTest.Write(btTest); // Call `WriteFile` API 
//  sfTest.Flush();       // Call `FlushFileBuffers` API
}
swTest.Stop(); // Calculate the time-consuming start from `swTest.Start() `
// ...

そして、「デバイスのWindows書き込みキャッシュバッファーフラッシュをオフにする」オプションを有効にして、Samsung 950pro NVMeディスクで実行します。

結果は次のとおりです。

D:\tmp> test        // without sfTest.Flush();
00:00:00.729766     // use 0.73 seconds without FlushFileBuffers()

D:\tmp> test        // with sfTest.Flush();
00:00:06.736167     // use 6.74 seconds with FlushFileBuffers()

そのFlushFileBuffersため、システムによって要求が省略されていないことがわかります（FlushFileBuffersオプションが有効になっていても、Windowsは呼び出しを無視しません）。