Pull to refresh

Comments 29

в сравнении с bcache и flashcache разница в производительности есть?
Не сравнивал, честно. Такое сравнение было бы хорошо провести, конечно, тем более, что оно достойно отдельной полноценной статьи.
Если на HDD использование LUKS не вызывает вопросов, то на SSD включение TRIM понижает защищённость информации.

Понижает, но не настолько значительно, что бы нужно было отказываться от TRIM.
Лично мне кешировать на SSD страшно, именно в плане того что я не могу быть уверен что _оно_правда_записалось_ и не пропадет при внезапном выключении.
Штуки требующие реально много IOPS предпочитаю размещать на RAID1 из пары SSD + полные и инкрементные бекапы на другой машине.
Возможно просто инерционность мышления.
Чтобы не было страшно, есть стратегии read-only и write-through. Реально страшно только тогда, когда используется write-back.
Использую flashcache в режиме writeback в течение полугода на /home рабочего лаптопа.
Раза 4 за это время аварийно завершался (паника, зависания из-за перегрева, батарейка разрядилась в 0). Не потерялось вообще ничего.
Автор описал write-back режим для RAID-контроллеров без батарейки.
Очень часто можно встретить такое описание в подобных статьях.
В этом режиме все пишется на SSD и никуда не денется при случайно перезагрузке, по сути оно дозапишется при старте системы.
Так работают RAID-контроллеры с батарейкой и тем более новое поколение контроллеров с встроенным SSD для write-кеша.
Как не денется? А то, что в памяти было и не успело дописаться на SSD диск? Одно дело хомяк подкэшировать, где один тпс раз в год, и другое дело — раздел, где есть активная запись.
В который раз уже пишу, попробуйте базу данных погрузить миллионом транзакций и вырубить питание. Денется еще как.
Также как и денется любой буфер в памяти при перезагрузке.
Речь о том что никуда не денется с SSD, а не из буфера записи.
Это понятно. Но только на уровне кэша журнала нет, как понять, какие блоки dirty а какие нет? Уже так просто не получится.
Говорили, что журнал вроде есть, например в bcache, но вот как-то не помогает особо.

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

А вообще — спасибо вам!
Я в последнее время как раз начал задаваться вопросами совместной работы HDD и SSD и теперь, после прочтения вашей статьи, получил ответы на большинство интересовавших меня вопросов.
Немного не линукс, но тоже nix семейство. Недавно сделал на маке fusion drive, это логический диск из SSD и HDD. Работать стало значительно быстрее. Поэтому смело экспериментируйте, оно того стоит. :)
Я правильно понимаю, что в случае использования гибридных HDD описанный в статье механизм кеширования данных реализован на уровне контроллера диска?


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

Пример из man-а eio_cli:
$ eio_cli create -d /dev/sdc1 -s /dev/sdd1 -c SDC1_CACHE
Тогда не понятно что и куда оно пишет на винт. Да и вообще, зачем ему устройство жесткого диска? Ведь SSD намного быстрее жесткого диска. Скажите пожалуйста где об этом можно почитать подробнее. Спасибо.
Не совсем понял, что именно вам не понятно, но попробую ещё раз. Вся структура данных на жёстком диске сохраняется. Она не меняется. А на SSD выносится дисковый кеш. При этом кешируемым объектом может быть как жёсткий диск в целом, так и отдельный раздел, а кеш тоже можно вынести или на весь SSD, или на отдельный его раздел.

Может, так понятнее.
ZFS очень требовательна к оперативной памяти. Так что не альтернатива.
Требования к оперативной памяти 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.
Вы используете ZFS на Sloaris/FreeBSD или проект zfsonlinux?
Какое это имеет значение? У ZFS поведение одинаково на всех ОС, на которые она портирована.
1. Здесь статья про Linux, где нет порта ZFS в стабильной версии
2. Если вы используете zfsonlinux хотел поинтересоваться опытом использования.
1. И не будет — лицензии CDDL и GPLv2 несовместимы в принципе.
2. Проект ZoL портирует на Linux все наработки Illumos. Подробнее об опыте использования можно прочитать в обсуждении темы: habrahabr.ru/post/152853/
Но это ещё не всё! Люди получают опыт, создавая NAS'ы на ZFS под Linux, и делятся им здесь:
forum.ixbt.com/topic.cgi?id=11:44629:2632#2632 (чтобы далеко не ходить).
1. С каких пор на стабильность софта влияет лицензия? Речь о проблемах с ZoL;
2. Это я уже все видел, и за пределы рунета ходил, ни одной success story в enterprise там нет.
Мои же тесты давали kernel panic на больших нагрузках при работе с iSCSI.
Возможно за пару месяцев много воды утекло, но с учетом скорости разработки сомневаюсь что там со временем баги прибывают медленнее чем правятся.
Sign up to leave a comment.

Articles

Change theme settings