Какова вся функция «Отключение очистки буфера кэша записи Windows на устройстве»

В Windows 7 с помощью диспетчера устройств, вызова свойств диска и перехода на вкладку «Политики» имеется 2 элемента переключателя. Кеш записи, о котором этот вопрос не идет.

и

[X] Отключите очистку буфера кэша записи Windows на устройстве <--- только этот!

Microsoft вкладывает отказ от ответственности для этого элемента. «Чтобы предотвратить потерю данных, не устанавливайте этот флажок, если устройство не имеет отдельного источника питания, который позволяет устройству очищать свой буфер в случае потери питания».

Проще говоря, что это меняет для записи файлов, сохранения файлов, копирования файлов?

1. Изменение действий записи для параноидальных программ: (факт или вымысел)
Изменит ли способ, которым записи сбрасывают работу для программы, которая заставляет происходить очистку кеша? Некоторые программы стремятся завершить запись, не размышляя, способны ли эти программы продолжить защитную запись, или же это изменится и для этих программ?

2. Типы
затрагиваемых программ. Какие типы действий / программ будут или не будут затронуты изменением? Тип, некоторые программы передаются по потоку, некоторые быстро записывают, некоторые непрерывны, некоторые являются защитными (или любой другой тип, который вы можете определить простыми словами).

3. Видели ли вы что-нибудь или даже эталон?
Если настройка включена, каковы наблюдаемые изменения в письменной форме? Любые свободные примеры наблюдаемого изменения в поведении. или не заметил никаких изменений в поведении?

4. Что такое задержка или задержка:
мы знаем, что большинство из этих действий выполняются очень быстро на большинстве компьютеров. В конечном итоге данные будут записаны. Относительно скорости привода значение времени?

Для целей моего вопроса существующий риск не является одним из вопросов, и если вы хотите его покрыть, он не будет мешать.

То, что означает «Очистка буфера в кеше записи», является почти обманом, но ссылка для другой ОС. Хотя у A есть некоторая информация, даже термин, использованный в ссылке, не совпадает. Это также не отвечает на самые важные вещи, которые пользователь хотел бы знать, которые я попытался изложить здесь.

1. Ваше утверждение в первом вопросе - выдумка. Такие вызовы Windows API, как и прежде, гарантируют, что данные будут полностью переданы на физический носитель, даже если очистка буфера записи отключена. Таким образом, программы, которые «безопасны» и знают, что они делают, будут в порядке. Такие вызовы, как в .NET и т. Д., В конечном итоге вызывают этот API.FlushFileBuffers() FileStream.Flush()

2. Программы, которые выполняют много операций дискового ввода-вывода без FlushFileBuffers()непосредственного вызова или какого-либо вспомогательного API, который в итоге вызывает его, увидят наиболее заметное увеличение производительности. Например, если вы выполняете несущественный ввод-вывод, когда все в порядке, если данные теряются, например, BOINC (если он потерян, вы просто повторно загружаете файл или пытаетесь пересчитать вычисления), вы можете избежать вызова FlushFileBuffers()и просто вызовите API как WriteFile()- данные будут буферизироваться для записи, но на самом деле они не будут записываться в течение потенциально длительного времени, например, когда дескриптор файла закрыт или когда программа завершается. К сожалению, также возможно, что в случае сбоя системы (например, BSOD) все данные будут потеряны, поэтому это действительно важночто если вы имеете дело с любыми ценными / несменяемыми данными, которые вы действительно вызываете FlushFileBuffers(), включена ли очистка буфера или нет! В противном случае простая ошибка драйвера (например, в вашем графическом драйвере) может привести к потере большого количества данных.

3. Не могу найти никаких тестов, но вы заметите это больше с программами, которые соответствуют описанию во втором пункте выше.

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, происходят в ОЗУ, и диск не перемещается, пока не пройдет 5 секунд с момента первой записи, а затем самые последние данные (из строки 7) будут записаны в блок (1) и записываются только данные, записанные в блок (2).
• Записи, происходящие в строках 10 и 13, которые перезаписывают данные в блоках (1) и (2), должны быть снова записаны на диск
• Таким образом, общее количество раз, когда этот блок (1) записывается в ОЗУ, равно 3, а на диск 2. Общее количество раз, когда этот блок (2) записывается в ОЗУ, составляет 2, а на диск - 2.

С автоматическими 5 секундами буфером промывки от (эффекта флажка в вашем вопросе):

• Записи, происходящие в строках 2, 5, 7, 10 и 13, происходят в ОЗУ, и диск не перемещается, пока не будет выполнена строка 14, а затем последние данные (из строк 10 и 13) будут записаны в блоки (1). и (2). Старые данные из строк 2, 5 и 7 никогда не попадают на жесткий диск!

Учитывая, что занятая система может производить от сотен до десятков тысяч операций записи в файлы в секунду, это очень важно для производительности, особенно на традиционных вращающихся жестких дисках (на SSD это менее впечатляет). Как правило, объем оперативной памяти в 20 раз выше, чем у жестких дисков, хотя этот разрыв меньше у твердотельных накопителей.

Причина, по которой они говорят, что вы должны использовать резервное питание от батареи, заключается в том, что вы не хотите, чтобы записанные данные в ОЗУ на 35 минут записывались в ОЗУ и не записывались на диск только потому, что ваш программист ленился и не звонил FlushFileBuffers(), а затем сбой питания. Конечно, резервная батарея не защищает вас от ошибок драйверов, которые вызывают BSOD ....

В поддержку ответа ChatBot Джона Кавила я написал небольшую тестовую программу:

// ...
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() `
// ...

И запустите его на диске Samsung 950pro NVMe с включенной опцией «Отключить очистку буфера кэша записи Windows на устройстве».

Результат:

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запрос не опускается системой (Windows не игнорирует FlushFileBuffersвызов, даже если параметры включены).