Что такое cache в жестких дисках

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

Для управления кэшированием записей на диске откройте Панель управления - Диспетчер устройств .

В разделе Дисковые устройства дважды щелкните нужный диск.

Перейдите на вкладку Политики

Быстрое удаление

Это значение обычно является оптимальным выбором для устройств, которые может понадобиться часто отключать от системы, таких как USB-устройства флэш-памяти, SD, MMC, Compact Flash или аналогичные карты памяти и другие внешние подключаемые устройства хранения.

Если выбран параметр Быстрое удаление , то Windows управляет командами, передаваемыми устройству, используя метод, называемый сквозным кэшированием . При сквозном кэшировании устройство работает с командами записи, как если бы кэш отсутствовал. Кэш может обеспечить небольшой выигрыш в быстродействии, но акцент ставится на обеспечение максимальной безопасности данных путем перехвата команд, передаваемых основному устройству хранения. Основное преимущество состоит в предоставлении возможности быстро удалять устройство хранения без риска потери данных. Например, при случайном извлечении флэш-диска из своего порта вероятность потери данных, записываемых на него, значительно уменьшается.

Этот вариант обычно является оптимальным для устройств, которые должны обеспечить максимально возможное быстродействие; для устройств, редко удаляемых из системы. Если выбрано это значение и устройство отключается от системы до того, как на него записываются все данные (например, при удалении USB-устройства флэш-памяти), то данные могут быть потеряны.

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

Запись кэша на диск

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

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

Как изменить для устройства параметры кэширования записей?

Большинство ориентированных на потребителя устройств хранения, например USB-устройства флэш-памяти, карты памяти SD или MMC или внешние диски, не позволяет изменять параметры кэширования для устройства. Внутренние жесткие диски с интерфейсами SATA или SAS, поставляемые с Windows, обычно позволяют изменять эти параметры (зависит от изготовителя устройства). Чтобы понять возможности кэширования, предоставляемые конкретным устройством, и определить, какие параметры лучше всего соответствуют вашим потребностям, обратитесь к документации, предоставляемой изготовителем.

Дополнительные сведения о предотвращении потери данных

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

Также следует осторожно удалять съемные устройства хранения, такие как USB-устройства флэш-памяти, карточки памяти SD, MMC или Compact Flash, внешние диски. При использовании параметра Безопасное удаление Windows сможет защитить данные пользователя в большинстве сценариев. Но определенные драйверы или приложения могут не соответствовать модели Windows, что может привести к потере данных при удалении подобных устройств. По возможности перед удалением из системы любого внешнего устройства хранения следует вызвать приложение «Безопасное удаление».

Источники: справочная документация Windows.

AZPC - Персональный компьютер от А до Я. Интернет-портал о компьютерах под управлением Windows.

Напомню, что утилита Seagate SeaTools Enterprise позволяет пользователю управлять политикой кэширования и, в частности, переключать новейшие SCSI-диски Seagate между двумя разными моделями кэширования — Desktop Mode и Server Mode. Этот пункт в меню SeaTools носит название Performance Mode (PM) и может принимать два значения — On (Desktop Mode) и Off (Server Mode). Отличия между этими двумя режимами чисто программные — в случае Desktop Mode кэш-память жесткого диска разбивается на фиксированное число сегментов постоянного (одинакового) объема и далее они используются для кэширования обращений при чтении и записи. Причем, в отдельном пункте меню пользователь даже может сам назначать количество сегментов (управлять сегментированием кэша): например, вместо дефолтных 32 сегментов проставить другое значение (при этом объем каждого сегмента пропорционально уменьшится).

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

Тогда мы смогли выяснить, что использование новых накопителей Seagate Cheetah в режиме «Desktop» (при фиксированном сегментировании по умолчанию — на 32 сегмента) вместо дефолтного «Server» с динамическим сегментированием способно немного поднять производительность дисков в ряде задач, более характерных для настольного компьютера или медиа-серверов. Причем, эта прибавка порой может достигать 30-100% (!) в зависимости от типа задачи и модели диска, хотя в среднем она оценивается величиной 30%, что, согласитесь, тоже неплохо. Среди таких задач — рутинная работа настольного ПК (тесты WinBench, PCmark, H2bench), чтение и копирование файлов, дефрагментация. При этом в чисто серверных приложениях производительность накопителей почти не падает (если и падает, то незначительно). Впрочем, заметный выигрыш от использования Desktop Mode мы смогли наблюдать только на диске Cheetah 10K.7, тогда как ее старшей сестрице Cheetah 15K.4 оказалось почти все равно, в каком из режимов работать над настольными приложениями.

Пытаясь разобраться дальше, как влияет сегментирование кэш-памяти этих жестких дисков на производительность в различных приложениях и какие режимы сегментирования (какое количество сегментов памяти) более выгодно при выполнении тех или иных задач, я исследовал влияние количества сегментов кэш-памяти на производительность диска Seagate Cheetah 15K.4 в широком диапазоне значений — от 4 до 128 сегментов (4, 8, 16, 32, 64 и 128). Результаты этих исследований и предлагаются вашему вниманию в этой части обзора. Подчеркну, что данные результаты интересны не только сугубо для этой модели дисков (или SCSI-дисков Seagate в целом) — сегментирование кэш-памяти и выбор количества сегментов — это одно из основных направлений оптимизации firmware, в том числе, настольных дисков с интерфейсом ATA, которые сейчас также оснащаются преимущественно буфером 8 Мбайт. Поэтому описанные в данной статье результаты производительности накопителя в различных задачах в зависимости от сегментирования его кэш-памяти имеют отношение и к индустрии настольных ATA-накопителей. А поскольку методика испытаний была описана в первой части, переходим непосредственно к самим результатам.

Впрочем, прежде, чем перейти к обсуждению результатов, взглянем чуть подробнее на устройство и работу сегментов кэш-памяти диска Seagate Cheetah 15K.4, чтобы лучше понимать, о чем идет речь. Из восьми мегабайт для собственно кэш-памяти (то есть для кэширующих операций) здесь доступно 7077 Кбайт (остальное — служебная область). Эта область делится на логические сегменты (Mode Select Page 08h, byte 13), которые используются для чтения и записи данных (для осуществления функций упреждающего чтения с пластин и отложенной записи на поверхность диска). Для обращения к данным на магнитных пластинах сегменты используют именно логическую адресацию блоков накопителя. Диски этой серии поддерживают максимум 64 сегмента кэш-памяти, причем длина каждого сегмента равна целому числу секторов диска. Объем доступной кэш-памяти, по всей видимости, распределяется поровну между сегментами, то есть если сегментов, скажем, 32, то объем каждого сегмента равен примерно 220 Кбайт. При динамической сегментации (в режиме PM=off) количество сегментов может меняться винчестером автоматически в зависимости от потока команд от хоста.

Приложения для серверов и настольных компьютеров требуют различных операций кэширования от дисков для обеспечения оптимальной производительности, поэтому сложно обеспечить единую конфигурацию для наилучшего выполнения этих задач. По мнению Seagate, для «настольных» приложений требуется сконфигурировать кэш-память так, чтобы быстро отвечать на повторяющиеся запросы большого количества небольших сегментов данных без задержек на упреждающее чтение смежных сегментов. В серверных задачах, напротив, требуется так сконфигурировать кэш, чтобы обеспечить поступление больших объемов последовательных данных в неповторяющихся запросах. В этом случае более важна способность кэш-памяти хранить больше данных из смежных сегментов при упреждающем чтении. Поэтому для Desktop Mode производитель рекомендует использовать 32 сегмента (в ранних версиях Cheetah использовались 16 сегментов), а для Server Mode адаптивное количество сегментов стартует всего с трех на весь кэш, хотя в процессе работы может и увеличиваться. Мы в своих экспериментах по поводу влияния количества сегментов на производительность в различных приложениях ограничимся диапазоном от 4 сегментов до 64 сегментов, а в качестве проверки «прогоним» диск также при 128 сегментах, установленных в программе SeaTools Enterprise (программа при этом не сообщает, что данное количество сегментов в этом диске недопустимо).

Результаты тестов физических параметров

Графики скорости линейного чтения при разном количестве сегментов кэш-памяти приводить никакого смысла нет — они одинаковы. А вот по измеренной тестами скорости работы интерфейса Ultra320 SCSI можно наблюдать весьма любопытную картину: при 64 сегментах некоторые программы начинают неправильно определять скорость работы интерфейса, снижая ее более чем на порядок.

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

Об эффективности работы алгоритмов отложенной записи firmware диска и кэширования записываемых данных в буфере накопителя можно попытаться судить по тому, как падает среднее измеренное операционной системой время доступа при записи относительно чтения при включенном write-back кэшировании накопителя (оно в наших тестах было всегда включено). Для этого мы обычно используем результаты теста C"T H2benchW, но в этот раз дополним картину и тестом в программе IOmeter, паттерны чтения и записи для которой использовали стопроцентно случайный доступ блоками по 512 байт с единичной глубиной очереди запросов. (Разумеется, не следует думать, что average write access time на двух диаграммах ниже реально отражает данную физическую характеристику накопителей! Это лишь некий программно измеряемый при помощи теста параметр, по которому можно судить об эффективности кэширования записи в буфере диска. Реальное заявленное производителем среднее время доступа при записи для Cheetah 15K.4 составляет 4,0+2,0=6,0 мс). Кстати, предвидя вопросы, замечу, что в данном случае (то есть когда в диске разрешена отложенная запись) накопитель рапортует хосту об успешном завершении команды записи (статус GOOD) сразу, как только они записаны в кэш-память, а не непоседственно на магнитный носитель. Этим и обусловлено меньшее значение измеренного извне average write access time, чем для аналогичного параметра при чтении.

По результатам этих тестов налицо ясная зависимость эффективности кэширования случайной записи мелких блоков данных от количества сегментов кэш-памяти — чем больше сегментов, тем лучше. При четырех сегментах эффективность резко падает и среднее время доступа при записи возрастает почти до значений при чтении. А в «серверной моде» число сегментов в данном случае, очевидно, близко к 32. Случаи 64 и "128" сегментов полностью идентичны, что подтверждает программное ограничение на уровне 64 сегментов сверху.

Интересно, что тест IOmeter в простейших паттернах на случайный доступ блоками 512 байт дает совершенно такие же значения при записи, что и тест C"T H2BenchW (с точностью буквально до сотых долей миллисекунды), тогда как при чтении IOmeter показал несколько завышенный результат во всем диапазоне сегментирования — возможно, разница в 0,1-0,19 мс с другими тестами на время случайного доступа при чтении обусловлена какими-то «внутренними» причинами для IOmeter (или же размером блока 512 байт вместо 0 байт, как требуется в идеале для таких измерений). Впрочем, результаты «по чтению» у IOmeter практически совпадают с таковыми для дискового теста программы AIDA32.

Быстродействие в приложениях

Переходим к тестам производительности накопителей в приложениях. И первым делом, попробуем выяснить, как хорошо диски оптимизированы для многопотоковой работы. Для этого я традиционно использую тесты в программе NBench 2.4, где файлы размером 100 Мбайт записываются на диск и читаются с него несколькими одновременными потоками.

Данная диаграмма позволяет нам судить об эффективности алгоритмов многопотоковой отложенной записи жестких дисков в реальных (а не синтетических, как было на диаграмме со средним временем доступа) условиях при работе операционной системы с файлами. Лидерство обоих SCSI-дисков Maxtor при записи несколькими одновременными потоками не вызывает сомнений, однако у Читы мы уже наблюдаем некий оптимум в районе между 8 и 16 сегментами, тогда как при более высоких и более низких значениях скорость диска на данных задачах падает. Для Server Mode число сегментов, очевидно, равно 32 (с хорошей точностью:)), а "128" сегментов — это, на самом деле, 64.

При многопотоковом чтении ситуация для дисков Seagate явно улучшается по сравнению с дисками Maxtor. Что же касается влияния сегментации, то, как и при записи, мы наблюдаем некий оптимум ближе к 8 сегментам (при записи он был ближе к 16 сегментам), а при очень высоком сегментировании (64) скорость диска существенно понижается (как и при записи). Отрадно, что Server Mode тут «отслеживает базар» хоста и меняет сегментирование с 32 при записи на ~8 при чтении.

Теперь посмотрим, как диски ведут себя в «преклонных», но до сих пор популярных тестах Disk WinMark 99 из пакета WinBench 99. Напомню, что мы проводим эти тесты не только для «начала», но и для «середины» (по объему) физического носителя для двух файловых систем, а на диаграммах приведены усредненные результаты. Безусловно, данные тесты не являются «профильными» для SCSI-накопителей, и мы приводя тут их результаты скорее отдаем дань уважения самому тесту и тем, кто привык судить о скорости диска по тестам WinBench 99. В качестве «утешения» заметим, что эти тесты с определенной долей достоверности покажут нам, какова производительность этих enterprise-накопителей при выполнении задач, более характерных для настольного компьютера.

Очевидно, что оптимум сегментирования есть и здесь, причем при малом количестве сегментов диск смотрится невыразительно, а при 32 сегментах — наилучшим образом (возможно, именно поэтому разработчики Seagate «сместили» дефолтную настройку Desktop Mode с 16 до 32 сегментов). Впрочем, для Server Mode в офисных (Business) задачах сегментирование не совсем оптимально, тогда как для профессиональной (High-End) производительности сегментирование более чем соптимизировано, заметно обгоняя даже оптимальную «постоянную» сегментацию. Видимо, именно в процессе выполнения теста она меняется в зависимости от потока команд и за счет этого получается выигрыш в общей производительности.

К сожалению, такой оптимизации «по ходу теста» не наблюдается для более свежих «трековых» комплексных тесты оценки «настольной» производительности дисков в пакетах PCMakr04 и C"T H2BenchW.

На обоих (а точнее — на 10 различных) «треках активности» интеллект Server Mode заметно уступает оптимальной постоянной сегментации, которая для PCmark04 равна примерно 8 сегментам, а для H2benchW — 16 сегментам.

Для обоих этих тестов 4 сегмента кэш-памяти оказывается очень нежелательным, да и 64 тоже, и сложно сказать, к чему больше тяготеет в своем выборе Server Mode в данном случае.

В противовес этим, безусловно, все же синтетическим (хотя и очень похожим на реальность) тестам — совершенно «реальный» тест скорости работы дисков с временным файлом программы Adobe Photoshop. Здесь ситуация гораздо позрачнее — чем больше сегментов, тем лучше! И Server Mode это почти «уловила», воспользовавшить 32 сегментами для своей работы (хотя 64 было бы еще чуточку лучше).

Тесты в Intel Iometer

Переходим к задачам, более характерным для профилей использования SCSI-накопителей — работе различных серверов (DataBase, File Server, Web Server) и рабочей станции (Workstation) по соответствующим паттернам в программе Intel IOmeter версии 2003.5.10.

С имитацией сервера базы данных успешнее всех справляется Maxtor, а для Seagate выгоднее всего использование Server Mode, хотя по сути последняя очень близка к 32 постоянным сегментам (объемом примерно по 220 кбайт каждый). Меньшее или большее сегментирование в данном случае оказывается хуже. Впрочем, это паттерн слишком прост по виду запросов — посмотрим, что будет для более комплексных паттернов.

При имитации файлового сервера лидирует снова адаптивная сегментация, хотя отставание от нее 16 постоянных сегментов ничтожно (32 сегмента тут чуть хуже, хотя тоже вполне достоны). При малом сегментировании наблюдается ухудшение на большой очереди команд, а при слишком большом (64) любая очередь вообще противопоказана — видимо, в этом случае слишком малым оказывается размер секторов кэша (менее 111 Кбайт, то есть всего 220 блоков на носителе), чтобы эффективно кэшировать приемлемые по размеру объемы данных.

Наконец, для Web-сервера мы видим даже более занятную картину — при НЕединичной очереди команд Server Mode равноценна любому уровню сегментирования, кроме 64, хотя на единичной она чуть лучше всех.

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

Что касается паттерна «рабочая станция», тот здесь Server Mode явно лучше всех.

А оптимум для постоянной сегментации находится на уровне 16 сегментов.

Теперь — наши паттерны для IOmeter, более близкие по назначению настольным ПК, хотя определенно показательные и для enterprise-накопителей, поскольку и в «глубоко профессиональных» системах жесткие диски львиную долю времени считывают и записывают большие и маленькие файлы, а также иногда копируют файлы. А поскольку характер обращений в данных паттернах в данных паттернах в тесте IOmeter (по случайным адресам в пределах всего объема диска) более характерен именно для систем серверного класса, то и важность этих паттернов для исследуемых дисков выше.

Чтение крупных файлов снова лучше дается для Server Mode, за исключением непонятного провала на QD=4. Однако небольшое количество крупных сегментов явно предпочтительнее для диска на этих операциях (что, в принципе, предсказуемо и отлично согласуется с результатами для многопотокового чтения файлов, см. выше).

Спорадическая запись крупных файлов, напротив, пока «не по зубам» интеллекту Server Mode, и здесь выгоднее постоянная сегментация на уровне 8-16 сегментов, как и при многопоточной записи файлов, см. выше. Отдельно отметим, что на этих операциях крайне вредным является большое сегментирование кэша — на уровне 64 сегментов. Однако оно оказывается полезным для операций с чтением мелкими файлами при большой очереди запросов:

Думаю, именно это использует Server Mode для выбора адаптивного режима — уж очень похожи их графики.

Вместе с тем, при записи мелких файлов по случайным адресам 64 сегмента снова провальны, а Server Mode здесь уступает постоянной сегментации с уровнем 8-16 сегментов на кэш, хотя видно старание Server Mode использовать оптимальные настройки (только с 32-64 сегментами на очереди 64 вышла незадача;)).

Копирование крупных файлов — явная неудача Server Mode! Здесь явно выгоднее сегментирование с уровнем 16 (это оптимум, поскольку 8 и 32 хуже на очереди 4).

Что же касается копирования мелких файлов, то 8-16-32 сегмента здесь практически равноценны, обгоняя 64 сегмента (как это ни странно), а Server Mode немного «чудит».

По результатам геометрического усреднения данных для случайного чтения, записи и копирования крупных и мелких файлов получаем, что наилучший в среднем результат дает постоянное сегментирование с уровнем всего 4 сегмента на кэш (то есть размеры сегментов более 1,5 Мбайт!), тогда как 8 и 16 сегментов примерно равноценны и почти не отстали от 4 сегментов, а вот 64 сегмента явно противопоказаны. Адаптивная Server Mode в среднем лишь немного уступила постоянной сегментации — проигрыш одного процента вряд ли можно считать заметным.

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

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

Выводы

Проведя во второй части нашего обзора более детальное исследование влияния сегментирования кэш-памяти на быстродействие накопителя Seagate Cheetah 15K.4 в разнообразных задачах, хочется отметить, что разработчики недаром назвали режимы кэширования так, как они их назвали: в Server Mode действительно нередко проводится адаптация сегментирования кэш-памяти под выполняемую задачу и это, порой, приводит к весьма неплохим результатам — особенно при выполнении «тяжелых» задач, среди которых и серверные паттерны в Intel IOmeter, и тест High-End Disk WinMark 99, и случайное чтение мелких блоков по всему диску… Вместе с тем, нередко выбор уровня сегментирования кэш-памяти в Server Mode оказывается неоптимальным (и требует дальнейшей работы по улучшению критериев анализа потока команд хоста), и тогда вперед выходит Desktop Mode с фиксированным сегментированием на уровне 8, 16 или 32 сегментов на кэш. Причем, в зависимости от типа задачи иногда выгоднее использовать 16 и 32, а иногда — 8 или всего 4 сегмента памяти! Среди последних — многопотоковые чтения и запись (как случайные, так и последовательные), «трековые» тесты вроде PCMark04 и потоковые задачи с одновременным чтением и записью. Хотя «синтетика» на случайный доступ при записи явно показывает, что эффективность отложенной записи (по произвольным адресам) существенно снижается с уменьшением числа сегментов. То есть налицо борьба двух тенденций — и именно поэтому в среднем эффективнее использовать 16 или 32 сегмента на 8-мегабайтный буфер. При удвоении объема буфера можно предсказать, что выгоднее сохранить количество сегментов на уровне 16-32, но за счет пропорционального увеличения емкости каждого сегмента средняя производительность накопителя может существенно повыситься. Видимо, даже неэффективное нынче в большинстве задач сегментирование кэша с 64 сегментами при удвоении объем буфера может оказаться очень полезным, тогда как использование в этом случае 4 и даже 8 сегментов станет малоэффективным. Впрочем, данные выводы сильно зависят еще и от того, какими блоками операционная система и приложения предпочитают оперировать с накопителем, и файлы какого размера при этом используются. Вполне возможно, что при изменении окружения оптимум сегментирования кэш-памяти может сместиться в ту или иную сторону. Ну а мы пожелаем Seagate успехов в оптимизации «интеллекта» Server Mode, которая, в определенной мере, может сгладить эту «системозависимость» и «задачезависимость», научившись наилучшим образом подбирать самое оптимальное сегментирование в зависимости от потока команд хоста.

Самый известный Алёша рунета делится шокирующей информацией.
http://www.exler.ru/blog/item/12406/?25

Помнится, в девяностых годах я на различных компьютерах, которым важна была производительность при работе с жестким диском, использовал так называемые кеш-контроллеры: это были платы, снабженные слотами для обычной оперативной памяти, в которые вставлялся определенный объем этой памяти, и она с помощью платы использовалась для кеширования данных с жесткого диска. Такая штука очень заметно ускоряла работу с жестким диском, особенно при использовании графических пакетов, вроде Corel Draw.

Особенно при использовании графических пакетов, вроде Corel Draw. Именно так.
(треск разрываемых шаблонов, глухой удар головы об стол )

Для начала определимся, что из себя представляет аппаратный дисковый кэш.
По большому счёту, это - кусок оперативы небольшого размера, "вшитый" в электронику винчестера.

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

Если какой-либо файл часто используется системой, то он будет помещён в дисковый кэш, чтобы 1) не дёргать лишний раз диск и 2) ускорить доступ к этому файлу. Убийство двух зайцев.

Вообще говоря, в кэш помещается не файл, а любое содержимое аппаратных блоков диска, которое часто читается. Например, служебные данные файловой системы. Или MBR. Или 12 килобайт из середины гигабайтного файла БД. Диск своё содержимое не различает, ему всё равно.
Ситуация с файлом приведена для наглядности.

Проблема в том, что в 90-е годы диски выпускались или без кэша, или он был слишком мал для хранения необходимых данных. И эта проблема действительно решалась использованием кэш-контроллеров.

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

По относительной скорости жёсткие диски недалеко ушли от скорости в 90-х годах: они до сих пор являются самой медленной деталью компьютера. Но развитие технологий позволило поместить в диски достаточный объём кэш-памяти. Достаточный для того, чтобы необходимость в отдельных кэш-контроллерах отпала.

Плюс, в юниксовых ОС дополнительным кэшем выступает "лишняя" (неиспользуемая) оперативная память. Так называемый, программный дисковый кэш . Иногда его называют "буферным кэшем", но это несколько другое.

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

Не так давно эти кеш-контроллеры стали возвращаться, но уже в образе SSD-дисков. Сначала появились так называемые гибридные диски - обычные жесткие диски, в которых также был встроен отдельный SSD небольшого размера (16-32 Гб), который использовался исключительно для кеширования.

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

А сейчас стали выпускать отдельные SSD, которые также используются именно для кеширования

Читай - обычные SSD с красной надписью «Cache Only».

Сегодня распространенным накопителем информации является магнитный жесткий диск. Он обладает определенным объемом памяти, предназначенным для хранения основных данных. Также в нем имеется буферная память, предназначение которой заключается в хранении промежуточных данных. Профессионалы называют буфер жесткого диска термином «cache memory» или же просто «кэшем». Давайте разберемся, зачем нужен буфер HDD на что влияет и каким обладает размером.

Буфер жесткого диска помогает операционной системе временно хранить данные, которые были считаны с основной памяти винчестера, но не были переданы на обработку. Необходимость наличия транзитного хранилища обусловлена тем, что скорость считывания информации с HDD накопителя и пропускная способность ОС значительно различается. Поэтому компьютеру требуется временно сохранять данные в «кэше», а только затем использовать их по назначению.

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

Стоит отметить, что размер «cache memory» зависит от конкретной модели диска. Раньше он составлял около 8 мегабайт, причем такой показатель считался удовлетворительным. Однако с развитием технологий производители смогли выпускать микросхемы с более большим объемом памяти. Поэтому большинство современных винчестеров обладают буфером, размер которого варьируется от 32 до 128 мегабайт. Конечно, наибольший «кэш» устанавливается в дорогие модели.

Какое влияние оказывает буфер жесткого диска на производительность

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

Однако если ПК используется для обработки файлов большого размера, то «кэш» утрачивает свою актуальность. Ведь информация не сможет поместиться на микросхемах, объем которых невелик. В результате пользователь не заметит увеличения производительности компьютера, поскольку буфер практически не будет использоваться. Это происходит в случаях, если в операционной системе будут запускаться программы для редактирования видеофайлов и т. д.

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

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

Идея кэширования основывается на так называемой гипотезе о локальности ссылок . Эта гипотеза заключается в следующем. Если в какой-то момент времени произошло обращение к определенному участку данных, то в ближайшее время можно с высокой вероятностью ожидать повторения обращений к тем же самым данным или же к соседним участкам данных. Конечно, локальность ссылок нельзя считать законом, однако практика показывает, что эта гипотеза оправдывается для подавляющего большинства программ.

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

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

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

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

Какой из блоков, хранящихся в кэше, следует выбрать для вытеснения, чтобы сократить общее количество обращений к диску? Это крайне важный вопрос, и если он будет решаться неправильно, то вся работа системы может затормозиться из-за постоянных обращений к диску.

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

Среди алгоритмов, используемых на практике, лучшим считается алгоритм LRU (Least Recently Used, в вольном переводе «давно не использовавшийся»). Он заключается в следующем: выбирать для вытеснения следует тот блок, к которому дольше всего не было обращений. Здесь как раз используется принцип локальности ссылок: раз обращений давно не было, то, вероятно, их и не будет в ближайшее время.

Как на практике реализуется выбор блока по правилу LRU? Очевидное решение – при каждом обращении к буферу записывать в его заголовке текущее время, а при выборе для вытеснения искать самую раннюю запись – слишком громоздко и медленно. Есть гораздо лучшая возможность.

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

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

На рис. 2‑3 показан массив буферов, связанный в список.

Теперь о «грязных» буферах. В каких случаях должна выполняться их «очистка», т.е. запись блока данных из кэш-буфера на диск? Можно назвать три таких случая.

· Выбор блока для вытеснения из кэша.

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

· Операция принудительной очистки всех буферов либо только буферов, относящихся к определенному файлу. Подобная операция может выполняться для повышения надежности хранения данных, как страховка от возможных сбоев. В ОС UNIX, например, очистка всех буферов традиционно выполняется каждые 30 с.

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

«Узким местом» кэширования дисков является поиск требуемого блока данных в кэше. Как было описано выше, для этого система просматривает заголовки буферов. Если кэш состоит из нескольких сотен буферов, время поиска будет ощутимо. Один из возможных приемов ускорения поиска, используемый в UNIX, показан на рис. 2‑4.

В UNIX каждый кэш-буфер может входить одновременно в два линейных списка. Один из них, называемый «списком свободных блоков», это знакомый нам LRU-список, используемый для определения блока, подлежащего вытеснению. Слово «свободный» не значит «пустой»; в данном случае это слово означает блок, не занятый в текущий момент в операции чтения/записи, выполняемой каким-нибудь процессом. Другой список называется «хеш-цепочкой» и используется для ускорения поиска нужного блока.

При записи в буфер данных, соответствующих некоторому блоку диска, номер хеш-цепочки, в которую будет помещен этот буфер, определяется как остаток от деления номера блока на N – количество хеш-цепочек. Для наглядности на рисунке принято значение N = 10. Таким образом, блоки с номерами 120, 40, 90 попадают в цепочку 0, блоки 91, 1, 71 – в цепочку 1 и т.д. Когда система ищет в кэше блок с определенным номером, она прежде всего по номеру блока определяет, в какой из хеш-цепочек этот блок должен находиться. Если блока нет в этой цепочке, то его вообще нет в кэше. Таким способом удается сократить поиск в лучшем случае в N раз (это если все цепочки окажутся одинаковой длины).

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

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