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

Question

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

а также

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

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

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

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

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

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

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

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

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

Answer 1

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

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 никогда не попадают на жесткий диск!

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

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

Answer 2

В поддержку ответа 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 даже если параметры включены).