Кеширование данных на SSD с помощью EnhanceIO

[@michaek]

в сравнении с bcache и flashcache разница в производительности есть?

[@pfactum]

Не сравнивал, честно. Такое сравнение было бы хорошо провести, конечно, тем более, что оно достойно отдельной полноценной статьи.

[@Snowly]

Если на HDD использование LUKS не вызывает вопросов, то на SSD включение TRIM понижает защищённость информации.

Понижает, но не настолько значительно, что бы нужно было отказываться от TRIM.

[@TheRaven]

Лично мне кешировать на SSD страшно, именно в плане того что я не могу быть уверен что _оно_правда_записалось_ и не пропадет при внезапном выключении.
Штуки требующие реально много IOPS предпочитаю размещать на RAID1 из пары SSD + полные и инкрементные бекапы на другой машине.
Возможно просто инерционность мышления.

[@pfactum]

Чтобы не было страшно, есть стратегии read-only и write-through. Реально страшно только тогда, когда используется write-back.

[@jcmvbkbc]

Использую flashcache в режиме writeback в течение полугода на /home рабочего лаптопа.
Раза 4 за это время аварийно завершался (паника, зависания из-за перегрева, батарейка разрядилась в 0). Не потерялось вообще ничего.

[@DLag]

Автор описал write-back режим для RAID-контроллеров без батарейки.
Очень часто можно встретить такое описание в подобных статьях.
В этом режиме все пишется на SSD и никуда не денется при случайно перезагрузке, по сути оно дозапишется при старте системы.
Так работают RAID-контроллеры с батарейкой и тем более новое поколение контроллеров с встроенным SSD для write-кеша.

[@sn00p]

Как не денется? А то, что в памяти было и не успело дописаться на SSD диск? Одно дело хомяк подкэшировать, где один тпс раз в год, и другое дело — раздел, где есть активная запись.
В который раз уже пишу, попробуйте базу данных погрузить миллионом транзакций и вырубить питание. Денется еще как.

[@DLag]

Также как и денется любой буфер в памяти при перезагрузке.
Речь о том что никуда не денется с SSD, а не из буфера записи.

[@sn00p]

Это понятно. Но только на уровне кэша журнала нет, как понять, какие блоки dirty а какие нет? Уже так просто не получится.
Говорили, что журнал вроде есть, например в bcache, но вот как-то не помогает особо.

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

[@sn00p]

Вот неплохое исследование, как оно себя ведет при потере питания. www.usenix.org/conference/fast13/understanding-robustness-ssds-under-power-fault
Вкратце: ничего хорошего ))

[@home_user]

Я правильно понимаю, что в случае использования гибридных HDD описанный в статье механизм кеширования данных реализован на уровне контроллера диска?

А вообще — спасибо вам!
Я в последнее время как раз начал задаваться вопросами совместной работы HDD и SSD и теперь, после прочтения вашей статьи, получил ответы на большинство интересовавших меня вопросов.

[@sevmax]

Немного не линукс, но тоже nix семейство. Недавно сделал на маке fusion drive, это логический диск из SSD и HDD. Работать стало значительно быстрее. Поэтому смело экспериментируйте, оно того стоит. :)

[@pfactum]

Я правильно понимаю, что в случае использования гибридных HDD описанный в статье механизм кеширования данных реализован на уровне контроллера диска?

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

[@iron_udjin]

Что-то я не впилю. Какое устройство жесткого диска нужно подсовывать, пустого чтоль? Если подсунуть диск с данными, оно не побьет таблицу разделов? Можно ли ему подсунуть не sda, а sda4, к примеру? В документации не нашел. Подскажите пожалуйста, уважаемые.

[@pfactum]

Можно хоть sda, хоть sda4, на сохранность данных не влияет — всё останется. Т.е., кешировать можно как весь диск, так и отдельный раздел.

[@home_user]

Судя по мануалу и в роли кеширующего устройства тоже можно указать раздел вместо всего диска.

Пример из man-а eio_cli:
$ eio_cli create -d /dev/sdc1 -s /dev/sdd1 -c SDC1_CACHE

[@pfactum]

Да, можно.

[@iron_udjin]

Тогда не понятно что и куда оно пишет на винт. Да и вообще, зачем ему устройство жесткого диска? Ведь SSD намного быстрее жесткого диска. Скажите пожалуйста где об этом можно почитать подробнее. Спасибо.

[@pfactum]

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

Может, так понятнее.

[@iron_udjin]

Теперь ясно. Спасибо!

[@iZENfire]

Проще использовать ZFS.

[@ZeroBit]

ZFS очень требовательна к оперативной памяти. Так что не альтернатива.

[@iZENfire]

Требования к оперативной памяти ZFS обусловлены ARC кэшем, который может изменять свой размер не только в сторону увеличения, но и в сторону уменьшения при запросе приложений на выделение памяти.
Например, у меня сейчас занято 2,7 ГБ (35%) оперативной памяти из 7,5 ГБ доступных. При этом в системе работают два Java-приложения (занимают 199 и 306 МБ, соответственно), оболочка Xfce (со всеми сервисами занимает около 300 МБ), Firefox (занимает 286 МБ) и Thunderbird (занимает 162 МБ).
Ещё на потребление памяти сильно влияет включение опции дедупликации файловых систем в ZFS, что может быть актуально на хостингах.

На SSD MLC можно создать кэш второго уровня L2ARC, который снизит требования к оперативной памяти и улучшит ответную реакцию операционной системы на часто запрашиваемый данные с дисков.

Intent Log (ZIL) можно разместить на небольшом высокопроизводительном SSD SLC, что ускорит операции записи на диски в несколько раз, так как ZFS фиксирует группы транзакций в синхронном режиме на более скоростном устройстве, а не на медленном HHD.

[@DLag]

Вы используете ZFS на Sloaris/FreeBSD или проект zfsonlinux?

[@iZENfire]

Какое это имеет значение? У ZFS поведение одинаково на всех ОС, на которые она портирована.

[@DLag]

1. Здесь статья про Linux, где нет порта ZFS в стабильной версии
2. Если вы используете zfsonlinux хотел поинтересоваться опытом использования.

[@iZENfire]

1. И не будет — лицензии CDDL и GPLv2 несовместимы в принципе.
2. Проект ZoL портирует на Linux все наработки Illumos. Подробнее об опыте использования можно прочитать в обсуждении темы: habrahabr.ru/post/152853/
Но это ещё не всё! Люди получают опыт, создавая NAS'ы на ZFS под Linux, и делятся им здесь:
forum.ixbt.com/topic.cgi?id=11:44629:2632#2632 (чтобы далеко не ходить).

[@DLag]

1. С каких пор на стабильность софта влияет лицензия? Речь о проблемах с ZoL;
2. Это я уже все видел, и за пределы рунета ходил, ни одной success story в enterprise там нет.
Мои же тесты давали kernel panic на больших нагрузках при работе с iSCSI.
Возможно за пару месяцев много воды утекло, но с учетом скорости разработки сомневаюсь что там со временем баги прибывают медленнее чем правятся.