Где вариант «я ничего не понял»? Использую SSD, но прокомментировать не могу

Даже не понимаю о чём речь. Просто /, /boot и /home в btrfs на SSD, ну а /tmp в tmpfs и /mnt/media в btrfs на HDD.

При синхронных нагрузках они синхронно могут выйти из строя.

Как страшно жить... Это теория или практика?

Так опрос дурацкий. Он не про SSD, а лишь про тех, кто его использует в качестве кеша HDD. Таких очень мало, и большинство владельцев SSD не в их числе.

Погляди на другие опросы, число прогосовавших примерно такое же. Из этого можно сделать определённые вывод, несмотря на отсутствие пункта «есть ssd, но не использую его в качестве кеша».

Так опрос дурацкий.

Вариант про журнал на SSD по смыслу вполне подходит к обычному use-case SSD как обычного накопителя. Мало того, что опрос дурацкий, так и часть ответов искажена.

Вариант про журнал на SSD по смыслу вполне подходит к обычному use-case SSD как обычного накопителя

храню на SSD только журнал ФС

Нет.

Как страшно жить... Это теория или практика?

Практика, так бывает даже с жёсткими дисками. А с SSD у которых ресурс каждой ячейки точно определён, такое очень вероятно при условии синхронной эксплуатации.

SSD по прежнему роскошь для народа.

Я не знаю. Я просто юзаю свой ssd как обычный винт, ниче не использую.

Ненужно. Снизить надежность для незначительного повышения быстродействия и очень незначительного повышения устойчивости дешифровке.

Мне кажется, надежность от этого не повысится, только скорость доступа.

Опрос не корректен. У меня есть несколько ССД но я не кэширую...

есть еще btier2, у него конечно свои тараканы, но всё равно dm-cache и bcache - фигня

Зачем вообще что-то кешировать? Для файлопомойки ( фильмы, игры по 50 гигов и т.д.) - hdd. Система + все проги ssd. Что есть такого мега объемного что его нужно хранить на hdd и кешировать?

: df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb4        65G   47G   15G  77% /
/dev/sda3       803G  720G   84G  90% /run/media/andrew/ntfs

А он хоть сколько-нибудь живой?

И tier требует зеркалирования быстрых дисков, иначе умер один — полетел весь том; *cache в общем случае живёт спокойно дальше.

Зачем вообще что-то кешировать?
/dev/sda3 ... ntfs

Да ты моя заинька.

Гамать на винде легче чем под вайном

Ну а зачем мне мнение большинства владельцев ssd? Нечего ткнуть в опросе — идёшь спокойно в толксы, как шёл.

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

Какую систему кэширования СХД на SSD вы используете или считаете предпочтительной?
- У меня нет SSD

Ох.

8 живых пользователей dm-cache, а как оно?

У меня с smq за 4 суток и 500 Гб записи оно в кеш даже журнал ФС не закинуло, только мусора насобирало. С mq и порогами write/read_promote_adjustment в 2 блока — тоже.

скажи пожалуйста, это фича для зфс?

да

Нечего ткнуть в опросе — идёшь спокойно в толксы, как шёл.

Нет, я хочу проголосовать в опросе! Опрос мне подсовывается прямо на главной, раздражает мой взор, обращает на себя моё внимание. А проголосовать нельзя, подходящего пункта нет. Фрустрация.

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

Скажем, работа с большим репозиторием на HDD - занятие не из приятных независимо от ФС, при этом из кэша в памяти он довольно быстро вытесняется другими данными, т.е. грубо говоря, после сборки проекта очередной git/svn status снова будет хрустеть дисками несколько минут. В L2ARC же репозиторий оседает и остаётся скорее всего до ребута, поэтому означенный status и другие операции выполняются всегда (кроме первого раза) считаенные секунды.

При этом это ещё дико выгодно и надёжно: основной массив остаётся на дешёвых ёмких HDD, а для кэша хватает маленького дешёвого SSD (мне 128G хватает с головой), при этом смерть кэша не приводит к потере данных. В другой ситуации либо вы выкидываете деньги на ветер делая SSD only массив и храня на нём bulk данные требующие редкого и медленного доступа, либо наслаждаетесь распихиванием данных между HDD и SSD руками. С L2ARC воткнул SSD и забыл, и просто получил ускорение работы с мелкими файлами на порядок.

харды прошлый век, ко-ко-ко, ssd у всех давно есть, ко-ко-ко. Что-то опрос показывает обратное.

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

Победили те, у кого нет ssd. То есть здравый смысл.

Мне кажется, надежность от этого не повысится, только скорость доступа.

Гуглим RAID 1 хотя бы.

Есть HDD, нет SSD

Я о ССД, Они просто все сдохнут где то в один момент или будут сыпаться один за одим...

А я тут причем? Сходи, купи.

Вот в точности как вы описали тут, я также использую Flashcache.

Где вариант «я не знаю, что отвечать» ?

8 живых пользователей dm-cache, а как оно?

У меня с smq за 4 суток и 500 Гб записи оно в кеш даже журнал ФС не закинуло, только мусора насобирало. С mq и порогами write/read_promote_adjustment в 2 блока — тоже.

На момент моего ответа «нас» уже 12 :)

Я использую lvmcache (тот же dm-cache) в сторадж сервере. Все настройки - дефолт (пробовал играться, но пока вернулся к дефолту, т.к. нужно, чтоб было с чем сравнивать). Режим кеширования - writeback в терминологии dm-chache.

Кейс использования: закешированный том имеет размер 440Гиг, размер кэша - 80Гиг. Том экспортируется по iSCSI в oVirt. На этом томе живут две виртуальные машины с дисками по 160Гиг (размер указываю, чтоб можно было оценить процентное соотношение), обе под управлением Win2008R2, сервисы - терминальные 1С и Office (с частичным(?) хранением файлов на диске ВМ), а так же AD.

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

Отвечая на вопрос «как оно?», исходя из графиков, скажу просто - более чем :)

Круто! Интересно, что у тебя будет, когда кеш забьётся полностью и нужно будет вытеснять. Я вот словил падение иопсов до скорости origin.

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

Куплю SSD когда про них перестанут говорить как о ненадежных, глючных и дорогих устройствах.

Прекрати читать компьютерные журналы десятилетней давности.

Для тех, кто не в теме, но "вынужден" отметиться

Для тех, у кого «только discard в fstab», у кого «нет ssd», у кого «на ssd только система», у кого «SSD есть, но не использую его для кеширования», у кого «все на ssd, нечего кешировать» - тем всем НЕ СЮДА. Опрос с четко обозначенной темой: «Кеширование СХД на SSD» (хотя я обозначил бы тему иначе, например, «Использование быстрых дисков ssd как кеш в СХД»). Не «попал» в тему - посмотри результат/мимокрокоди. Я, например, именно так делаю. Немного раздражает, что в теме увидели знакомую последовательность букв «SSD» значит надо отметиться вне зависимости от того по теме или нет.

Для тех, кому «кэширование на ssd ненужно», а особенно для тех, кому «ненужно» из-за того, что система у него на голом ssd, а файлопомойка на hdd, объясняю, что целью задачи, которая затронута в теме, была увеличение быстродействия бюджетных СХД.Разносить данные на быстрый и медленный диск можно тогда, когда заведомо известно какие из данных редко будут необходимы, а какие достаточно часто. Механизмы же кеширования позволяют в автоматическом(!) режиме отследить частоиспользованные данные и поместить их на быстрый диск. Например, если у вас на СХД база данных, то сложно какую-то таблицу держать на ssd, а остальные на hdd, в то время как кеширование на ssd вполне себе может решить подобную задачу.

И еще, кому «ненужно», донесите свою мысль о «ненужности» до facebook, где целая команда разработчиков трудилась над этой задачей, что в последствии вылилось в доступный всем flashcache.

ну справедливости ради, терабайтные и больше ssd пока еще роскошь :)

В общем, без претензии на объективность: bcache — для дома, для семьи, для живых дисков; dm-cache — для интерпрайза, который будет вкладываться в программистов на допиливание вместо покупки нормальной СХД.

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

У bcache есть режим writeback, который умеет отслеживать произвольные операции записи и последовательные. Так, например, при записи большого файла, данные помещаются сразу на hdd, минуя ssd, тем самым не забивая кеш. Но так работает до тех пор, пока fs поверх bcache.

Dm-cache работает с блоками данных, поэтому ему все равно будет поверх еще одно блочное устройство или сразу файловая система. У dm-cache тоже есть режим работы writeback, но это отнюдь не тот writeback, что у bchache. Алгоритм работы writeback в dm-cache таков: если блок данных перезаписан 8 раз (значение можно менять, 8 - стандартное), то такой блок будет помещен в кеш, и перезапись этого блока в 9-ый раз будет произведена только в кеше.

Поэтому произвольная запись небольших данных в варианте fs->bcache(writeback) с точки зрения пользователя системы выглядит лучше, чем в варианте fs->dm-cache(writeback).

Но если мы используем СХД, где храним диски виртуалок, то использование dm-cache будет предпочтительно, т.к. рано или поздно (при достаточном объеме кеша) диски виртуалок «переползут» в кеш, что существенно ускорит дисковую подсистему этих самых виртуалок.

Алгоритм работы writeback в dm-cache таков: если блок данных перезаписан 8 раз (значение можно менять, 8 - стандартное), то такой блок будет помещен в кеш, и перезапись этого блока в 9-ый раз будет произведена только в кеше.

Это в политике mq, которая считает блоки/bios. И там ещё такой нюанс: не за 8 или n раз, а за n ticks. То есть совсем не сразу.

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

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

все интересно кешировать. ZIL? ну это же не на десктопе...

я вот только что на десктопе запустился!) кеширование при помощи lvm.

  LV   VG          LSize           Origin	Data%  Meta%    Cachemode 
  home vg    1.78t           [home_corig] 1.19   4.03           writeback            

CacheReadHits    CacheReadMisses  CacheWriteHits   CacheWriteMisses
29780            84354             4658		75701

Отвечая на вопрос «как оно?», исходя из графиков, скажу просто - более чем :)

той же дорогой идем)

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

Запись-то, конечно. А кешировать чтение интересно при большом кол-ве random reads. И чем больше современных уровней абстракции (все виды vm, рейды и проч.) тем больше дисперсия чтения.

при большом кол-ве random reads

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

единственный кейс, который я встречал, чел раздавал торренты с гигабитного линка (или такое есть на сидбоксе) и тупо упирался в иопсы, а раздач было на пару терабайт

Я о ССД, Они просто все сдохнут где то в один момент или будут сыпаться один за одим...

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

во-первых, все-таки есть две ситуации: сервер и десктоп. я не буду спорить, какие ситуации редкие, а какие нередкие, но приведу примеры с random read.

например любые базы проще на SSD вынести

вот этого не понял вообще. если бд уже более 500гб, растер, куча реплик. что значит «любые»?? нет, конечно. чем больше БД, тем дороже. может, не очень удачный пример, потому что ssd стали по карману любой организации, но всеравно в какой-то момент это еще не оч.рентабельно.

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

теперь еще юзкейс с виртуалками. Filth выше очень правильно использует кеш под образы. Любая ОС в виртуалке будет по своему «выравнивать» чтение. Ты можешь поручиться, что оно все будет линейное на твоем host?

Вангую набигание маководов с ОЛОЛО-ОДНИНИЩЕБРОДЫ!11!!111

А что, эта тема разве чем-то принципиально отличается от любой другой темы на лоре, где они точно так же могли бы набижать? Днищеброды...

СХД на SSD

обыденность, даже у моего кота это есть

А мне SSD и не нужен. А купить не выйдет в связи с ситуацией на Украине.