Диски SATA, которые обрабатывают запись, кэширующуюся правильно?
Вообще говоря, в прямом ответе на Ваш вопрос, я не знаю ни о каких главных брендах дисков SATA, что сам диск имел ошибки относительно правильного функционирования с включенным кэшированием записи. Таким образом, с точки зрения диска только, диск делает то, что он, как предполагается, делает с кэширующейся точки зрения. Я также отметил бы что, даже когда кэширование записи включено, что задержка от записи на диск на кабеле SATA к вращающимся медиа, физически обновляемым, является все еще очень малой (~50 к 100 мс обычно). Это не похоже на грязные данные кэша, будет просто находиться там в течение многих секунд, за один раз..... диск постоянно пытается получить грязные данные от кэша на физические среды, как только это может. Это не просто вопрос безопасности данных, но и один из того, чтобы быть готовым принять будущие записи без любой задержки (т.е.: запишите регистрацию).
Проблема, которая возникает, когда кэширование включено, - то, что запись заказывает диску по кабелю SATA, и порядок записи к вращающимся медиа не является тем же. Это никогда не может вызывать проблему, ЕСЛИ у Вас нет потери питания или системного катастрофического отказа, прежде чем все содержание кэша доберется до диска. Почему?->
Проблема, которая может, возникает, вот относительно устойчивости транзакции файловая система и/или содержание файла базы данных к этим неисправным потерянным записям. В действительности те потенциально потерянные неисправные записи могут теоретически повредить целостность логики формирования транзакций, которая имела бы, иначе были гарантированы записями на диск, происходящими в очень определенном порядке с медиа.
Теперь, конечно, разработчики файловой системы, базы данных, RAID-контроллеры, и т.д. знают (или конечно должно знать) этого явления относительно кэширования записи. Кэширование записи чрезвычайно желательно с точки зрения производительности в сценариях ввода-вывода типа наиболее произвольного доступа. На самом деле имение в наличии кэширования записи является основным элементом способности обладать любым реальным преимуществом для более усовершенствованной Организации очередей собственных команд (NCQ), которая поддерживается на более новом SATA и последних нескольких поколениях реализаций PATA. Так, гарантировать порядок физическим средам в такие определенные критические времена, файловую систему и/или приложение, и т.д. может конкретно запросить сброс кэшей записи к медиа. При завершении этого синхронизирующего запроса - все ожидающее от (потенциально) буферов файлов, кэширования диска ОС, физический диск, кэширующийся и т.д., на самом деле отсутствует на медиа на проектирование системы транзакции при правильных критических операциях. Таким образом, это происходит правильно, если программисты выполняют правильный вызов наверху, И каждый элемент этой цепочки слоев программного и аппаратного обеспечения сделал их задание правильно. т.е.: нет никаких ошибок в этом отношении в диске, RAID-контроллерах, дисковых драйверах, кэшах ОС, файловой системе, механизме базы данных, и т.д. Это - много программного обеспечения, что все должно работать точно правильное. Кроме того, проверка правильности в этом отношении является очень трудной, потому что почти в любой ситуации обычно порядок записи не имеет значения вообще.... и сбой питания и отказывает, сценарии являются трудными тестами для построения. Так, в конце, "выключающем запись, кэширующуюся" на одном или нескольких различных слоев и/или значениях этого термина...., имеет репутацию "зафиксировать" определенные виды проблем. В действительности отключение поведений кэширования записи RAID-контроллера или Дисковых кэшей ОС или Диска, и т.д. избегает одной или нескольких ошибок в системе..... и источнике таких сведений.
Так или иначе, возвращаясь к ядру вопроса: Под SATA определенная обработка всего чтения с диска / команды записи и команды кэша сброса четко определена спецификациями SATA. Кроме того, производства дисков должны были подробно изложить документацию для каждой модели диска или семейства дисков, описывающего их реализацию и соответствие к этим правилам как этот пример для дисков Барракуды Seagate. В частности, посмотрите детали команды SATA SET FEATURES, которая управляет диском операционный режим, и конкретно 82-я опция может использоваться для отключения кэширования диска на уровне диска, потому что значение по умолчанию является, конечно, кэшированием записи, включенным на всех дисках, о которых я знаю. Если бы Вы действительно хотели отключить кэш, то эта команда должна быть сделана в начале каждого, подвозят сброс или питание, и обычно находится под контролем дисковых драйверов для Вашей операционной системы. Вы смогли поощрять свой драйвер ОС устанавливать этот режим через IOCTL и/или Реестр, Устанавливающий вещь типа, но это значительно различается.
-
1Одна редакционная статья к моему ответу: Аппаратные RAID-контроллеры заметно ошибочны относительно многих, нумеруют проблем включая проблемы относительно их внутренней реализации кэширования записи. Я понятия не имею, почему, но анекдотическим образом говорящий RAID-контроллеры, кажется, часть самого ошибочного программного обеспечения, когда-либо записанного с точки зрения чего-то, что имеет такое широкое использование. Это, конечно, платит для использования очень основных, хорошо установленных и широко развернутых аппаратных средств RAID от очень уважаемых поставщиков..... и даже затем исправляет к нетривиальным проблемам, кажутся слишком частыми! – Tall Jeff 30 May 2009 в 15:17
-
2Спасибо Jeff. I' ve, делая большое чтение в это и I' m примерно столь же запутанный, как я когда-либо был. Я думаю проблема I' m борющийся с теперь имеет отношение к " запишите barriers" которые позволяют приложениям и файловым системам давать слою блока команду гарантировать надлежащее упорядочивание записи с помощью различных доступных механизмов. К сожалению, существуют все виды проблем с реализацией барьеров. LVM, с одной стороны, по-видимому, doesn' t поддерживают их, даже если базовые устройства делают. Кроме того, мне кажется, что у системных администраторов должна быть опция наличия fsync, вызывают сброс кэша диска – eas 9 June 2009 в 20:53
-
3@eas - " запишите barriers" термин, к которому Вы обращаетесь к, мне принимаю, тот же основной механизм, что я назвал " sync" или " flush" из кэшей в моем ответе выше. К Вашей точке это может инициируемый на различных слоях в доступе к файлу " stack". для построения истинного барьера записи это должно взять влияние через все слои, которые имеют незаконченные данные записи (который является: грязные кэши или буферы обратной записи) вниз до физических сред для фактической работы, как предназначено. Любая разъединенная ссылка в той цепочке - то, что представляет потенциальные проблемы, когда записи переупорядочиваются. – Tall Jeff 10 June 2009 в 23:38
Это был мой опыт, что дисковый контроллер с кэш-памятью с аварийным батарейным питанием отключит кэш на диске. Я не знаю о способе отключить дисковый кэш иначе. Даже если бы Вы могли бы отключить дисковый кэш, производительность значительно пострадала бы.
Для низкой стоимости optoin, можно использовать недорогой UPS, который может сигнализировать системе для организованного завершения работы.
-
1Мой комментарий выше должен был быть добавлен здесь. I' m, все еще изучая этот сайт. – eas 30 May 2009 в 09:56
-
2Некоторые RAID-контроллеры действительно отключают дисковый кэш все время, некоторый don' t и у некоторых есть установка. Это поведение существенно зависит от какой RAID controller' s кэширующаяся реализация стратегии похож. В некоторых реализациях они действительно хотят управлять порядком записи к диску...., и в других он имеет значение меньше. Я ссылаюсь на некоторые проблемы здесь в моем ответе. – Tall Jeff 30 May 2009 в 15:21
Как Вы говорите, надлежащий RAID-контроллер с аварийным батарейным питанием будет дорогим, но можно найти контроллеры Dell Perc5/i на eBay за 100£ (150$), и особенно с RAID5 скорость контроллера как Perc5/i поразит Вас. У меня есть несколько серверов с Perc5/is и шесть дисков массивы RAID5, и они среди самых быстрых дисков I, когда-либо видели. Специально для приложений базы данных быстрые диски действительно улучшат производительность.
Я стиснул бы зубы и купил бы RAID-контроллер.
МЛАДШИЙ
Насколько я понимаю, fsync (), фальсифицирование является свойством RAID-контроллеров с аварийным батарейным питанием, не дисков. RAID-контроллер содержит батарею, которая может привести в действие ее кэш записи, пока электроснабжение не восстановлено диску, и запись может безопасно посвятить себя диску. Это позволяет контроллеру сразу возвратиться к ОС, поскольку это делает некоторый уровень гарантии, что запись будет записана в диск.
Нужно отметить, если кэш с обратной записью дисков заполнится, то записи заблокируются, пока кэш не имеет быть записанным обратно к диску. Это означает, что кэш обычно не как эффективный под длительными записями.
Сколько IOPS делает Вас, приложение требует? Вы уверены, что ограничиваетесь кэшем записи дисков, или что маленькое (по сравнению с памятью Вашего сервера) на диске будет иметь выгоду?
-
1Тестирование I' m выполнение теперь должен определить конверт производительности нашего приложения, таким образом, мы можем выяснить, как лучше всего увеличиться и. Кэш диска может быть относительно маленьким, но с записью, кэширующейся на нем, дает диску способность переупорядочить записи (когда соответствующий), который похож на него, может удвоить поддержанную пропускную способность записи. – eas 9 June 2009 в 21:03
Я использую систему RAID с суперконденсатором , а не батарею для поддержания кеша. Батареи изнашиваются, подлежат контролю, замене и представляют собой потенциальную точку отказа в этом отношении. Конденсатор заряжается при запуске, очищает кеш-память при сбое питания ИБП, работает практически вечно, не требует мониторинга и т. Д. Однако, если вы не ведете бизнес на грани бедности (что не редкость в наши дни), вам нужен ИБП. и программное обеспечение, которое аккуратно выключает систему в случае сбоя - я обычно даю ему 5-15 минут (в зависимости от нагрузки ИБП и, следовательно, имеющейся батареи) перед отключением, если питание возобновится.
Во время грозы вы можете (или можете есть - системы питания становятся лучше) вижу мерцающие огни, иногда прямо перед тем, как они погаснут. Это устройство, называемое реклоузером. Это автоматический выключатель, который при срабатывании пытается замкнуть разомкнутый переключатель в случае, если перегрузка была кратковременной, что в большинстве случаев бывает. Если он не может оставаться закрытым после, скажем, трех попыток, он остается открытым. Какому-то бедному парню нужно выйти под дождь и разобраться с этим. Не жалей его, хотя зарабатываем вдвое больше, чем мы с тобой, и вдвое больше, если сверхурочная работа, это опасная работа.
Одно из заблуждений при использовании кэшей с обратной записью на диск состоит в том, что они теряют данные только при потере питания. Это не всегда так, особенно на устройствах sATA. Если на устройстве sATA есть ошибка (например, ошибка FW в крайнем случае или ошибка контроллера) и оно сбрасывается или сбрасывается извне, нет гарантии, что данные в кэше обратной записи по-прежнему доступны после зависания.
Это может привести к сценариям, в которых устройство имеет временную ошибку, сбрасывается, происходит потеря данных при потере любого грязного кеша, и это происходит тихо выше уровня блоков драйверов.
Хуже того, отключение кеша диска через Инструменты ОС также будут потеряны при перезагрузке устройства, поэтому даже если кэш устройства отключен в начале дня, при перезагрузке устройства оно снова включит кэширование с обратной записью. При следующем сбросе устройство потеряет данные.