Является ли» отключить Windows write-cache buffer flushing » безопасным на ноутбуке?

внутренний жесткий диск моего ноутбука немного медленный. Я посмотрел на свойства диска и есть два варианта:

Как видите, первый вариант уже отмечен, а второй — нет. Я слышал, что второй вариант действительно может ускорить ситуацию, но это также звучит очень рискованно. Безопасно ли это делать на ноутбуке, который редко отключается от сети переменного тока? (но все еще имеет батарею)

3 ответов

Да это безопасно. Windows никогда не использует all батареи. Когда уровень заряда батареи достигает определенного минимума (

6-7%), он автоматически сбрасывает кэш накопителя и переходит в спящий режим. Он делает это до уровень заряда батареи слишком низок, чтобы спящий режим, который требует определенного количества «сока», чтобы вращать жесткий диск достаточно долго, чтобы скопировать оперативную память на диск.

Эмпрически, мне пришлось переустановить windows 3 раза на 2 отдельных ноутбуках, используя этот параметр. Никогда не приходилось этого делать, когда он не установлен. Имел ноутбуки 4 года и 1 год, вероятно, побежал, чем около 50% с установкой 50% без. В настоящее время без. Недостаточно данных, чтобы доказать что-либо QED, но достаточно, чтобы убедить меня, что горе, связанное с доказательством вышесказанного, было совпадением, не стоит пользы от повышения производительности, я определенно не буду использовать его на системном диске.

потеря мощности-это не единственное, что вызывает физический сбой системы. На ноутбуках легко разлить напитки в клавиатурах, бросить их вниз по лестнице и различные другие опасности, пока диск вращается. Все, что внезапно отключает жесткий диск, будет немного безопаснее с включенным кэшированием записи. Я предлагаю оставить его включенным.

Низкая производительность диска при включенном кэшировании записи

Эта работа была прислана на наш «бессрочный» конкурс статей.

В данной статье речь пойдёт о Microsoft Knowledge Base Article 332023 — Slow Disk Performance with Write Caching Enabled (Низкая производительность диска при включенном кэше записи), а так же о некоторых связанных с этим вопросах. В какой-то степени она касается всех.

Краткое содержание статьи Microsoft Knowledge Base Article 332023.

реклама

В операционных системах Windows 2000 Sp3, Windows XP производительность некоторых операций записи на жёсткий диск (IDE, SCSI) может быть ниже ожидаемой при включенном кэше записи. Причиной является особенность работы кэша записи.

Когда кэширование записи включено, данные не записываются сразу на диск, а попадают в кэш. Непосредственная запись происходит через некоторое время (отложенная запись). Этим достигается повышение производительности.

В некоторых случаях важно произвести запись немедленно, минуя кэш. Это предотвращает потерю или повреждение данных в случае сбоев. Например, если при дефрагментации произойдет внезапная потеря питания, то данные, которые находятся в кэше записи и не успевают записаться на диск, будут потеряны. Ситуация усугубляется тем, что при отложенной записи в кэше может находиться достаточно много информации, как содержимого файлов, так и таблиц размещения файлов. Для повышения надёжности выполнения таких критичных операций, диску посылаются специальные команды, которые позволяют записывать данные немедленно, не используя кэш. Для IDE дисков применяется команда «Flush buffers» (на самом деле эта команда вызывает запись на диск содержимого кэша, но в данном случае это не важно).

Такая особенность работы драйверов диска была разработана изначально и позволяет повысить надёжность системы за счет некоторого снижения производительности критичных операций. Для пользователей Windows 2000, которым требуется максимальная скорость, Microsoft предлагает установить обновлённые драйвера диска (включены в Sp4) и специальную утилиту Dskcache.exe. Обновлённые драйвера добавляют опцию «Power protected write cache», а при помощи утилиты можно управлять настройкой кэша.

При включении опции «Power protected cache», команда Flush buffers диску не посылается. Этим исключается уменьшение производительности, но в случае потери питания при выполнении критичных операций все находящиеся в кэше диска данные теряются и возможно повреждение данных на диске. Ниже приведены возможные настройки и их эффект.

Write Caching (Кэш записи)	Power Protected (Защищенное питание)	Эффект
Disabled (Выключено)	N/A (Не доступно)	Диск не кэширует запись. Драйвер не посылает диску команды Flush buffers.
Enabled (Включено)	Disabled (Выключено)	Диск кэширует запись. Драйвер посылает диску команды Flush buffers для критичных операций. (Значения по умолчанию)
Enabled (Включено)	Enabled (Включено)	Диск кэширует запись. Драйвер не посылает диску команды Flush buffers для критичных операций.

Несмотря на заявления Microsoft, Power protected cache можно включить в Windows XP Sp1 и ранее. Необходимые для этого драйвера входят в Sp2 и прекрасно работают. В Windows 2000 наоборот не удалось заставить работать Power protected cache. Несмотря на выводимое сообщение, что Power protected cache включен, результаты тестов не менялись.

Где можно ожидать падения производительности при включенном кэшировании записи?

Падение производительности будет только при выполнении критичных операций записи. В частности при дефрагментации, при вызове API функций записи в реестр. Но само понятие критичной операции определяют разработчики программного обеспечения, все зависит от каждого конкретного приложения.

Проведённое мини исследование показало, что большинство программ работают без падения производительности. В том числе MS Word, копирование, распаковка архивов. Уменьшение скорости происходит в Business Disk WinMark 99, 1С:Предприятие. Можно ожидать падение производительности в некоторых профессиональных пакетах при операциях сохранения.

реклама

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

Какова величина падения производительности?

В случае многократной записи небольшими порциями, разница между записью используя кэш и минуя кэш может достигать 10 и более раз. В частности, в 1С:Предприятии при обработке справочников без использования транзакций разница приближается к двум порядкам.

Было произведено небольшое тестирование. В нем участвовали:

• WinBench 99 2.0 www.etestinglabs.com . Несмотря на свой возраст, этот пакет до сих пор является непременным атрибутом тестирования дисков. В отличие от большинства других программ, WinBench 99 формирует на диске отдельную папку, создаёт в ней набор файлов и эмулирует реальную работу приложений. Единственным его недостатком является сильная зависимость от системы. Влияние оказывает файловая система и драйвера. С другой стороны, если система остаётся постоянной, то результаты отражают реальную производительность дисков.
• 1С:Предприятие. Версия 7.7. Для тестирования использовалась реальная база 223 МБ (DBF формат). Замерялась скорость восстановления последовательности документов за 3 месяца. Эта операция является достаточно распространённой и, в некоторых случаях, выполняется часто.

Тестирование производилось при использовании:

• Windows 98. Эта операционная система не «знает» о существовании кэша жёсткого диска. После появления дисков с 8 МБ кэшем, была даже выпущена заплатка, которая при выключении питания делала паузу для того, чтобы диск успел записать все данные из кэша. Соответственно, никаких команд Flush buffers диску не посылается. Результаты приводятся справочно.
• Windows XP Power Protected Cache — Disabled. Кэш записи включен, команда Flush buffers диску не посылается.
• Windows XP Power Protected Cache — Enabled. Кэш записи включен, команда Flush buffers диску посылается.
• Windows XP nForce IDE SW driver 3.44. Установить последний драйвер 3.66 не удалось. Система просто не загружалась. Поэтому использовалась предыдущая версия драйвера.

Тестирование производилось на системе: CPU Athlon 2000 МГц, MB nForce2, RAM 512 МБ, Video R9000 64МБ 128бит, HDD WD400JB (40 ГБ, 8 МБ кэш).

Все тесты выполнялись на первом разделе C: — 8 ГБ, FAT32. Диск был частично заполнен данными, перед тестами была выполнена дефрагментация. Тесты WinBench 99 BUS выполнялись по 10 раз, а WinBench 99 HE по 5 раз. Результат усреднялся. Не было выявлено никакой разницы в загрузке процессора при дисковых операциях (где выше результаты, там, соответственно, и загрузка процессора была немного больше).

По полученным результатам можно сделать выводы:

• Power protected cache дает повышение производительности далеко не всегда, но там где дает, повышение значительно.
• Драйвер nForce IDE SW ведет себя аналогично Windows XP Power Protected Cache — Enabled. Разница незначительна, хотя и есть.
• В Windows 98 результаты WinBench 99 значительно хуже, чем в Windows XP. Но 1С:Предприятие работает быстрее в Windows 98, чем в Windows XP Power Protected Cache — Disabled.

Немного о IDE драйверах.

Кроме стандартных драйверов IDE контроллера, поставляемых Microsoft, существуют драйвера производителей «железа» — Intel Application Accelerator, VIA IDE Miniport Driver, nForce IDE SW Driver, драйвера от SIS. К этой же категории можно отнести и Maxtor MaxBoost. Протестировать все возможные драйверы не было возможности, но, основываясь на личных наблюдениях и по сообщениям в форумах о результатах WinBench 99, можно утверждать, что в каждом из этих драйверов команда Flush buffers при выполнении критичных операций записи не посылается диску. Этим самым при выполнении дефрагментации, записи в реестр, данные на диске подвергаются дополнительной опасности быть поврежденными при сбоях питания. Однако производители умалчивают об этом, заявляя о повышении производительности за счет логики IDE контроллера или использовании преимуществ их «железа».

Особо стоит отметить Intel Application Accelerator. Intel приводит достаточно много информации о достоинствах своего драйвера. Кроме того, имеются диаграммы:

реклама

Несмотря на то, что Intel Application Accelerator не тестировался, можно сделать выводы, что основной прирост производительности в WinBench 99 происходит из-за того, что команда Flush buffers диску не посылается. Обратите внимание, результаты WinBench 99 High-End Disk WinMark не приводятся, т. к. прироста производительности там нет или он очень мал. Уменьшение скорости загрузки Windows, скорее всего, обусловлено более быстрой инициализацией, но никак не повышением производительности дисковой подсистемы. Похожая ситуация наблюдается с драйверами nForce IDE SW. После смены их на стандартные, во время загрузки происходит несколько заметных пауз.

Судя по документации, Intel Application Accelerator использует в качестве дополнительного кэша оперативную память, т. е. работает аналогично Maxtor MaxBoost. При использовании диска с 2 МБ кэшем, он все-таки должен дать некоторый прирост производительности.

Пару слов можно сказать про личный опыт использования VIA IDE Miniport Driver. Во-первых, этот драйвер так же не посылает команду Flush buffers диску. Во-вторых, в нём были отмечены критические ошибки. Предыдущая версия некорректно себя вела на диске с 8 Мб кэша при завершении работы (питание отключалось до записи данных на диск из кэша), текущая версия 3.20b регулярно вызывала зависания системы, правда это случалось раз в 3 дня. При одном из зависаний произошла потеря информации. После перемещения файла с флэш накопителя на жёсткий диск, система зависла. При этом работало все, что не требовало обращения к диску (можно было переключаться между окнами). После перезагрузки выяснилось, что файл с флэш накопителя был удалён при перемещении, а на диск он не записался.

реклама

В операционных системах Windows 2000 и Windows XP стандартные драйвера диска для некоторых критичных операций записи на диск посылают команду Flush buffers, чтобы диск не использовал кэш. Этим достигается надёжность, за счет некоторого снижения производительности. При помощи утилиты Dskcache.exe и последних драйверов диска, включенных в Windows 2000 Sp4, Windows XP Sp2, можно повысить производительность дисковой подсистемы. При этом в случае сбоев (потери питания), данные диска подвергаются дополнительному риску быть поврежденными. Включение и отключение соответствующей опции можно производить «налету» без перезагрузки.

Драйвера Intel Application Accelerator, VIA IDE Miniport Driver, nForce IDE SW Driver, драйвера от SIS, Maxtor MaxBoost не посылают команду Flush buffers диску при выполнении критичных операций. Этим повышается производительность, но снижается надёжность. Например, если при выполнении дефрагментации будет отключено питание, то очень вероятно повреждение данных на диске. Некоторые производители «железа» используют особенность работы стандартных драйверов Microsoft, чтобы продемонстрировать несуществующее преимущество собственной продукции.

Результаты теста WinBench 99 Business Disk WinMark сильно зависят от того, посылается ли команда Flush buffers диску или нет. Во многих обзорах, в том числе и на уважаемых русскоязычных сайтах, не принимают это во внимание. Результаты оказываются сильно искажены. В частности, в сравнениях ATA (драйвер по умолчанию) с SATA (драйвер производителя), результаты WinBench 99 для ATA оказываются сильно заниженными. На основании этих искаженных результатов делаются выводы о значительном превосходстве в производительности SATA над ATA.

What is the whole function and effect of “Turn off Windows write-cache buffer flushing on the device”

In Windows 7, using the Device Manager, bringing up the properties of a disk, and going to the Policies tab, there are 2 switch items. The write cache, which this question it not about.

[X] Turn off Windows write-cache buffer flushing on the device Follow

2 Answers 2

Your assertion in the first question is fiction. Windows API calls such as FlushFileBuffers() will still ensure that the data gets all the way out to the physical media, even with write buffer flushing disabled. So, programs that are «safe» and know what they’re doing are going to be just fine. Calls such as FileStream.Flush() in .NET, etc. eventually call this API.

Programs that do a lot of disk I/O without calling FlushFileBuffers() directly, or any helper API that eventually calls it, would see the most noticeable performance increase. For instance, if you were running non-essential I/O where it’s okay if data gets lost, such as BOINC (if it gets lost you just re-download the file or attempt to re-compute the calculations), you could avoid calling FlushFileBuffers() , and just call an API like WriteFile() — the data will get buffered to be written, but it won’t actually be written for potentially a long time, such as when the file descriptor is closed, or when the program exits. Unfortunately it is also possible that if the system crashes (such as a BSOD), all the data is lost, so it is really important that if you are dealing with any kind of valuable / non-replaceable data that you do do call FlushFileBuffers() , whether buffer flushing is enabled or not! Otherwise a simple driver bug (for instance in your graphics driver) could cause you to lose a lot of data.

Can’t find any benchmarks, but you’ll notice it more with programs that fit the description in the second item above.

Syncing data to disk isn’t actually that fast, especially if it is done frequently in a tight loop. By default, if I recall correctly from reading Windows Internals books, NTFS by default syncs all dirty filesystem buffers to disk every 5 seconds. This is apparently a decent tradeoff between stability and performance. The problem with frequently syncing data is that it makes the hard drive do a lot of seeks and writes.

Consider the following pseudocode:

With automatic 5 second buffer flushing on:

• The writes occurring on lines 2, 5 and 7 occur in RAM and the disk doesn’t move, until 5 seconds have elapsed since the first write, and then the latest data (from line 7) gets written into block (1) and the only data written into block (2) gets written.
• The writes occurring on lines 10 and 13, which overwrite data in blocks (1) and (2), have to get written out to disk again
• So the total number of times that block (1) got written to RAM is 3, and to disk, 2. The total number of times that block (2) got written to RAM is 2, and to disk, 2.

With automatic 5 second buffer flushing off (the effect of the checkbox in your question):

• The writes occurring on lines 2, 5, 7, 10 and 13 occur in RAM and the disk doesn’t move, until line 14 is executed, and then the latest data (from lines 10 and 13) gets written into blocks (1) and (2). The old data from lines 2, 5, and 7 never hits the hard disk!

Considering that a busy system can experience between hundreds to tens of thousands of writes to files per second, this is great for performance, especially on traditional spinning hard drives (it’s less impressive on SSDs). RAM is 20 times faster than hard drives as a general measure, although that gap is less with SSDs.

The reason they say you should use a battery backup is that you don’t want to have 35 minutes worth of written data buffered in RAM that isn’t written to disk just because your programmer was lazy and didn’t call FlushFileBuffers() , and then have a power failure. Of course, a battery backup doesn’t protect you against driver bugs that cause a BSOD.