Для ядра Linux представлена (https://lkml.org/lkml/2013/9/1/55) реализация нового механизма кэширования на SSD-накопителях - dm-writeboost. Основным отличием новой системы от уже существующих механизмов DM-Cache (http://www.opennet.me/opennews/art.shtml?num=36814) и Bcache (http://www.opennet.me/opennews/art.shtml?num=35849) является ориентация на пакетную запись для продления службы SSD-накопителя и ускорения операций записи. Модуль dm-writeboost претендует на включение в экспериментальное дерево staging следующего выпуска ядра Linux.Dm-writeboost хранит информацию в лог-подобной последовательно заполняемой цикличной структуре для заполнения которой случайный набор операций записи накапливается и сбрасывается на SDD в пакетном режиме в виде большого непрерывного блока. Подобный подход позволяет значительно поднять эффективность записи - при использовании dm-writeboost потеря производительности кэширования случайных запросов составляет всего 3% по сравнению с последовательной записью. Например, при пропускной способности SSD-накопителя в 266MB/s, dm-writeboost обеспечивает запись со скоростью 259MB/s.
URL: https://lkml.org/lkml/2013/9/1/55
Новость: http://www.opennet.me/opennews/art.shtml?num=37864
Эээ... Асинхронный кэш записи в памяти? Нафига оно такое, это ж никакой надежности.
Перед тем как попасть на блочное устройство, данные кэшируются в оперативной памяти (если вы, конечно не сбрасываете их принудительно с помощью fsync()). Тут добавляется ещё один уровень кэширования, на SSD. Конечно, надёжность снизится: поскольку кэшируются вообще все операции записи на блочном устройстве, то перестаёт работать журналирование и в случае отключения питания не только потеряются данные, но и может быть нарушена структура ФС. Однако, если вы беспокоитесь о сохранности именно данных, то нужно в любом случае обеспечивать бесперебойное питание. Или всё время делать fsync-и с соответствующей многократной потерей производительности.
Структура ФС не может быть нарушена ибо операции записи атомарны. Просто часть данных не запишется, вместе с журналом конечно и будут сидеть на ssd. Собственно снижения надежности быть не должно
Структура ФС не нарушается не из-за атомарности, а из-за барьеров записи.
Просто, для опций, с которыми данные могут похериться, обычно пишут PROBABLY LOSS OF DATA.
И переспрашивают 3 раза.
И так понятно, что на серверах могут быть 2 блока питания, которые воткнуты в разные ИБП, плюс батарейка на рейд контроллере.
Например, при включении writeback на рейд контроллере, даже с батарейкой, GUI контроллера все равно уточнит "вы уверены?".
На стационарнике без упса - да.
Расчитано-же это на всякие компакти девайсы со всотоенной системой бесперебойного питания.
А смысл в отдельном модуле? Журнал на рам-диск и не парить мозг. :)
> Журнал на рам-диск и не парить мозг. :)Гениально, Ватсон. А лучше сразу данные на рамдиск. Правда потом, после факапа, придется парить мозг вопросом "ой, а куда это все делось?!" :)
> На стационарнике без упса - да.
> Расчитано-же это на всякие компакти девайсы со всотоенной системой бесперебойного питания.Батарейка вылетела/глюкнула и все.
а много ли таких накопителей, у которых их аппаратная архитектура не является открытой? И насколько тогда и труднее и хуже будет получаться разработка СПО под них?
(насколько такие чудотехники за границей стоят дешевле, чем у нас на Руси?)
1. Возможно
2. На 23%
3. На 107
Хм, автор забыл упомянуть сколько памяти при этом занимал кэш...
Почему в тексте новости у SSD-накопителя 266мбайт/с вместо 6Гбит/с, которые пишут в рекламах и характеристиках товаров?
Угадайте, кому лучше верить о скорости работы накопителей: маркетологам или разработчикам драйверов? Подсказка - зарплата вторых значительно слабее зависит от продаж.
6Гбит/с - это пропускная способность SATA/SAS-шины.
266мбайт/с - это скорость записи в ячейки памяти.
если запись последовательная, зачем тогда SSD, 10Krpm диска будет достаточно.
Ну как-бэ SSD можно ронять сильнее. Жрет меньше, весит меньше.
Делать проще! В НЖМД дофига металлообработки и офигительно сложная система сервомеханики. Не смотрите что сделана просто. Супер точно во первых, сложно в управлении во вторых.
> Ну как-бэ SSD можно ронять сильнее. Жрет меньше, весит меньше.
> Делать проще! В НЖМД дофига металлообработки и офигительно сложная система сервомеханики.
> Не смотрите что сделана просто. Супер точно во первых, сложно в
> управлении во вторых.НЖМД дешевле, и это перевешивает всю ту ерунду которую вы написали
Маркетологи такие маркетологи.
> если запись последовательная, зачем тогда SSD, 10Krpm диска будет достаточно.как бы движения головок и время на него никто не отменял
> как бы движения головок и время на него никто не отменялПлюс механика потенциально ненадежна и может отказать катастрофическим образом, например, запил поверхности - и все, прощай данные. С другой стороны флеш деградирует постепенно и общее состояние накопителя - относительно предсказуемо.
Только вот дохнут всё равно неожиданно :)
> Только вот дохнут всё равно неожиданно :)Да они дохнут изза контроллера.
Сдохших SSD (черт попутал поставить под кэш баз и кэш сквида) за последние 2 года, у меня 8 штук.
А вот сдохших HDD - ни одного.
Вопрос: что получается надёжнее, HDD или SSD?
У меня HDD на серверах ходят по 5-7 лет (трудно сейчас добыть диски SCSI 68-pin, только под заказ), SSD, больше года ни один не протянул.
> Сдохших SSD (черт попутал поставить под кэш баз и кэш сквида) за
> последние 2 года, у меня 8 штук.
> А вот сдохших HDD - ни одного.
> Вопрос: что получается надёжнее, HDD или SSD?
> У меня HDD на серверах ходят по 5-7 лет (трудно сейчас добыть
> диски SCSI 68-pin, только под заказ), SSD, больше года ни один
> не протянул.А ты лом в пилораму пробовал???
Под кэш сквида - купи 4 планки ДДР3-ЕСС.
А вот рэйд на ссдшках под базу сиквэлсервера дает винтам по балде от 6 до 11 раз!
> если запись последовательная, зачем тогда SSD, 10Krpm диска будет достаточно.Затем что SSD в целом куда быстрее. Много ли 10k RPM вообще выжимает под 300 мегов в секунду? Там же хоть RPM и выше, но плотность записи никакая, так что скорость передачи на блины не такая уж и фантастичная.
Оно и там и там не быстрее нитерфейса. 10K RPM SAS vs SATA-ii ... всяко может быть.
>> если запись последовательная, зачем тогда SSD, 10Krpm диска будет достаточно.
> Затем что SSD в целом куда быстрее. Много ли 10k RPM вообще
> выжимает под 300 мегов в секунду? Там же хоть RPM и
> выше, но плотность записи никакая, так что скорость передачи на блины
> не такая уж и фантастичная.200 выдают, без проблем, ставим 2 будет 400.
Читается то кеш не в пакетном режиме. А в весьма хаотическом.
> если запись последовательная, зачем тогда SSD, 10Krpm диска будет достаточно.Ну здрасьте, линейную скорость записи на 15krpm меряли?
>> если запись последовательная, зачем тогда SSD, 10Krpm диска будет достаточно.
> Ну здрасьте, линейную скорость записи на 15krpm меряли?меряли, ссд - быстрее.
пиписьки:
ХДД сигейты 15.7к 300Г в зеркале и ССД Интелы 520(вроде бы 240Г) так же в зеркале.
Гадать не будем, интел победил.Хотя отрыв был не столь колоссальный как на иопсах на тех же носителях
при работе с БД.
Как я писал выше - на обработке тяжелых запросов получали тесты от 6 до 11кратного увеличения скорости выполнения.