Комментарии 67
Вообще-то есть ещё режим readahead, который, по идее, должен обеспечить наибольшее ускорение, но он по-умолчанию выключен, берегут ресурс SSD.
Хм, чем это отличается от EnhanceIO?
Как минимум, тем, что опен-сорс. Жду такой же вопрос про flashcache.
Тогда не понимаю зачем вот это: www.stec-inc.com/wscgi-bin/PRSIL.sh/tsPortal/registTrialTS.htm
Вот это, конечно, круче чем у bcache:
EnhanceIO does not use device mapper. This enables creation and
deletion of caches while a source volume is being used. It's possible
to either create or delete cache while a partition is mounted.
Угу, он вырос из Flashcache. Круто. Я для написания статьи в свое время разбирал flashcache.
Вообще-то bcache тоже умеет на лету
A single cache device can be used to cache an arbitrary number of backing devices, and backing devices can be attached and detached at runtime, while mounted and in use (they run in passthrough mode when they don't have a cache).
EnhanceIO не готово к включения в ядро ;)
Как раз на lkml обсуждение сейчас: lkml.org/lkml/2013/1/11/341
Как раз на lkml обсуждение сейчас: lkml.org/lkml/2013/1/11/341
Немного опаснее. Не немного. Фатально опаснее.
Самый ощутимый прирост дает слишком ненадежный режим. Можно, конечно, надеяться на батарейки, но они ощутимо часто отказывают. Это так, не истина в последней инстанции, а примеры из личного опыта.
В последний раз у нас неожиданно упал сервер с postgresql, стоял flashcache в writeback. Мера была вынужденная, переселить пока некуда было, а без него вообще не шевелилось. Пару дней не дожил до переселения. Все нет больше базы. Восстановить не удалось. Остальные режимы дают профит либо маленький, либо под специфичные кейсы использования.
Штука хорошая, но чудес все равно не бывает. У нас отлично работает на проектах, где инфа может потеряться без проблем. и без проблем восстановиться потом. На что-то более серьезное — я бы не рискнул.
Самый ощутимый прирост дает слишком ненадежный режим. Можно, конечно, надеяться на батарейки, но они ощутимо часто отказывают. Это так, не истина в последней инстанции, а примеры из личного опыта.
В последний раз у нас неожиданно упал сервер с postgresql, стоял flashcache в writeback. Мера была вынужденная, переселить пока некуда было, а без него вообще не шевелилось. Пару дней не дожил до переселения. Все нет больше базы. Восстановить не удалось. Остальные режимы дают профит либо маленький, либо под специфичные кейсы использования.
Штука хорошая, но чудес все равно не бывает. У нас отлично работает на проектах, где инфа может потеряться без проблем. и без проблем восстановиться потом. На что-то более серьезное — я бы не рискнул.
Как я понял (поправьте меня если я не прав — на боевом сервере эти кэшеры пока не щупал) можно сделать зеркало, ну или к примеру, пятый RAID из SSD дисков и таким образом минимизировать риск до приемлимых величин (ну плюс бэкапы и грамотная репликация на уровне приложений должны добить остаток)
Не спасет. Кэш — это прямое и деструктивное вмешательство в логику работы файловой системы.
В режиме, когда данные сначала записываются на SSD, а потом на файлуху — это самый быстрый и привлекательный режим writeback — все делается примерно так. Я сейчас утрирую и механизм немного сложнее на самом деле.
Мы пишем, драйвер кэша разбивает все на блоки, какие-то сохраняет на SSD, какие-то коммитит на диск. Разбивка оригинальная для кэша, файлуха про нее ничего не знает. Мигает свет. С точки зрения файловой системы блоки в кэше — это мусор. Только драйвер кэша знает, как превратить этот мусор в нечто, что можно записать на диск и файлуха это поймет. Только после аварии он не знает, что можно записать, а что нет — кэш невалиден и писать его никуда уже нельзя.
В итоге мы имеем кучу неконсистентных данных на файловой системе и пачку странных данных на SSD, драйвер кэша тоже уже не знает что с ними делать.
Файлуха отремонтирует что можно, зафиксит журнал и отреплеит что можно. Это выглядит, как будто мы взяли и перемешали между собой содержимое рандомных файлов. К примеру, в файле с базой данных у вас запросто могут оказаться вкрапления сислога или другой базы данных или еще чего-нибудь, куда была еще запись на момент аварии.
Никакие рейды тут не спасут. Спасет только батарейка и нормальное завершение работы сервера в случае аварии.
Это справдливо для writeback. В остальных режимах не так фатально, но тоже неприятно.
В режиме, когда данные сначала записываются на SSD, а потом на файлуху — это самый быстрый и привлекательный режим writeback — все делается примерно так. Я сейчас утрирую и механизм немного сложнее на самом деле.
Мы пишем, драйвер кэша разбивает все на блоки, какие-то сохраняет на SSD, какие-то коммитит на диск. Разбивка оригинальная для кэша, файлуха про нее ничего не знает. Мигает свет. С точки зрения файловой системы блоки в кэше — это мусор. Только драйвер кэша знает, как превратить этот мусор в нечто, что можно записать на диск и файлуха это поймет. Только после аварии он не знает, что можно записать, а что нет — кэш невалиден и писать его никуда уже нельзя.
В итоге мы имеем кучу неконсистентных данных на файловой системе и пачку странных данных на SSD, драйвер кэша тоже уже не знает что с ними делать.
Файлуха отремонтирует что можно, зафиксит журнал и отреплеит что можно. Это выглядит, как будто мы взяли и перемешали между собой содержимое рандомных файлов. К примеру, в файле с базой данных у вас запросто могут оказаться вкрапления сислога или другой базы данных или еще чего-нибудь, куда была еще запись на момент аварии.
Никакие рейды тут не спасут. Спасет только батарейка и нормальное завершение работы сервера в случае аварии.
Это справдливо для writeback. В остальных режимах не так фатально, но тоже неприятно.
Тогда должно спасти дополнительное журналирование на уровне этой кэш-подсистемы
Именно, и у bcache такой журнал есть. Там вообще большой упор сделан на сохранность данных.
Было бы интересно посмотреть, как работает, про журнал именно в кэше я не знал. Или он не для всех режимов?
Не очень понятно, как он работает. Кэш же обманывает контроллер диска, операционку и, следовательно, файлуху.
Они уже получили сигнал, что операция записи успешно завершена, но на самом деле нет. Журнал файлухи, метаданные уже содержат информацию о том, каково будет на самом деле состояние файловой системы через несколько мгновений. Вот мигает свет. Эти несколько мгновений потом зареплеятся кэшем?
Так если прикинуть, журналирование кэша убьет практически весь профит от кэша ))
Не очень понятно, как он работает. Кэш же обманывает контроллер диска, операционку и, следовательно, файлуху.
Они уже получили сигнал, что операция записи успешно завершена, но на самом деле нет. Журнал файлухи, метаданные уже содержат информацию о том, каково будет на самом деле состояние файловой системы через несколько мгновений. Вот мигает свет. Эти несколько мгновений потом зареплеятся кэшем?
Так если прикинуть, журналирование кэша убьет практически весь профит от кэша ))
[ 11.700168] bcache: btree_journal_read() done
[ 11.719329] bcache: btree_check() done
[ 11.720356] bcache: journal replay done, 586 keys in 14 entries, seq 7162-7175
[ 11.722509] bcache: Caching sdc2 as bcache1 on set a31f0196-bbd6-4771-ac21-79ebafa96511
[ 11.724926] bcache: Caching sdb2 as bcache0 on set a31f0196-bbd6-4771-ac21-79ebafa96511
[ 11.724948] bcache: registered cache device sda
[ 11.764008] XFS (bcache0): Mounting Filesystem
[ 11.825803] XFS (bcache0): Ending clean mount
[ 11.836239] XFS (bcache1): Mounting Filesystem
[ 11.887738] XFS (bcache1): Ending clean mount
Почему после аварии кэш — невалиден? На SSD лежат метаданные — какие блоки dirty, какие нет. Запись в обход кэша на диск не производится. Почему бы просто не продолжить работу после ребута?
SSD все равно медленнее, чем память. Драйвер теряет все, что было в памяти и не успело попасть в метаданные. В таком случае даже пропажа одного бита, но непонятно где, делает весь кэш невалидным. Как-то так.
Да, но это по-моему не отличается от простого выдёргивания сервера из розетки, если там вообще нет никакого кэша. Мы действительно теряем всё, что только собиралось записаться на диск.
вообще-то пишут небольшими блоками чтобы была атомарность — и сначала пишем контрольную сумму и только после данные. Таким образом — если записали контрольную сумму, а не записали данный — то будет найден поврежденный блок.
> Кэш — это прямое и деструктивное вмешательство в логику работы файловой системы.
Очень интерестно… а что по твоему значит буква «B» в слове «bcache»?
Очень интерестно… а что по твоему значит буква «B» в слове «bcache»?
попробуйте fusionio ioTurbine — он работает примерно также, но на порядок надежнее (правда и на порядок дороже)
>Кэш же обманывает контроллер диска, операционку и, следовательно, файлуху.
Это с какого перепугу? Bcache работает как прокси и форматируется в любую ФС + имеет свой журнал.
Прямо здесь: bcache.evilpiepirate.org/ в features:
Это с какого перепугу? Bcache работает как прокси и форматируется в любую ФС + имеет свой журнал.
Прямо здесь: bcache.evilpiepirate.org/ в features:
Recovers from unclean shutdown — writes are not completed until the cache is consistent with respect to the backing device (Internally, bcache doesn't distinguish between clean and unclean shutdown).
Ну здрасьте. Как кэш может форматироваться в любую ФС, он с блоками работает. Там блоки и лежат, причем у всех по-разному.
Я сейчас говорю про режим writeback. И нет еще ни одного контроллера в мире в режиме writeback, который бы без батарейки переживал ребут. Это и дает в итоге производительность в ущерб надежности.
Рекавери работает везде, во flashcache тоже. На железных контроллерах. Но в двух других режимах.
Иначе сами посудите. Какой смысл писать на быстрый SSD, потом ждать, пока все запишется на медленный диск, а потом репортить успешность операции. Быстрее будет сразу писать на диск, минуя SSD ))
Читать — другое дело.
Я сейчас говорю про режим writeback. И нет еще ни одного контроллера в мире в режиме writeback, который бы без батарейки переживал ребут. Это и дает в итоге производительность в ущерб надежности.
Рекавери работает везде, во flashcache тоже. На железных контроллерах. Но в двух других режимах.
Иначе сами посудите. Какой смысл писать на быстрый SSD, потом ждать, пока все запишется на медленный диск, а потом репортить успешность операции. Быстрее будет сразу писать на диск, минуя SSD ))
Читать — другое дело.
Я знаю, что рекомендуют собрать рейд из SSD и хранить кэш там, но вот не могу понять смысла этого совета, если это не решает главной проблемы — обозначить после ребута какие блоки были dirty, а какие нет.
В случае просто с файлухой понятно, там можно отреплеить пару тройку транзакций и все вроде хорошо. Но как отреплеить кэш? Как драйвер кэша поймет, что нужно реплеить, если про файлуху и ее логику он не знает ничего?
>Но как отреплеить кэш?
Если озаботиться заранее, то нет проблем. Периодически в журнал кеша (не в памяти, а на ssd) дописывать, какие dirty-блоки уже записаны на диск. После ребута можно поднять этот журнал, поднять список блоков в очереди на запись, и дописать те, которые по журналу ещё не записаны.
>Как драйвер кэша поймет, что нужно реплеить, если про файлуху и ее логику он не знает ничего?
А ему и не надо ничего знать про fs. Достаточно дописать недописанные данные (см. выше), и отдать устройство fs, а она посмотрит и сделает весь recovery что нужно. Т.е. fs и знать не будет, что был write-back кеш, для нее будет выглядеть что просто запись оборвалась с какого-то момента (а именно, с того момента, когда данные ещё не записались на ssd).
Если озаботиться заранее, то нет проблем. Периодически в журнал кеша (не в памяти, а на ssd) дописывать, какие dirty-блоки уже записаны на диск. После ребута можно поднять этот журнал, поднять список блоков в очереди на запись, и дописать те, которые по журналу ещё не записаны.
>Как драйвер кэша поймет, что нужно реплеить, если про файлуху и ее логику он не знает ничего?
А ему и не надо ничего знать про fs. Достаточно дописать недописанные данные (см. выше), и отдать устройство fs, а она посмотрит и сделает весь recovery что нужно. Т.е. fs и знать не будет, что был write-back кеш, для нее будет выглядеть что просто запись оборвалась с какого-то момента (а именно, с того момента, когда данные ещё не записались на ssd).
Да нет этой проблемы. Метаданные итак хранятся на SSD.
А зачем? Ведь если по-умолчанию при старте считать, что все блоки dirty — то нету никакой проблемы, вы получите все данные с диска + изменённые блоки из ssd кэша. Если вдруг блоки окажутся одинаковыми — то никакой проблемы нету, если разные — то правильное содержание в ssd. Тут только 1 тонкий момент — надо на ssd хранить соответствие закешированного блока и блока на диске, а не только в оперативной памяти. И никакого replay делать не надо — только поднять список соответствия в память и сразу продолжить работу.
рейд из SSD нужен чтоб в случае сдыхания одного SSD кеш не помер.
кто же ставит SSD в сингле?
челвоек вон выше не понимает зачем рейд из SSD :)
Если кэш помер, то и ладно. Все равно в режиме writeback реплей не работает.
Под «зачем» я имел в виду «зачем обозначать как dirty после ребута», т.к. они ещё до ребута были известны и записаны.
У SSD вероятность спасения данных в случае зеркала сильно ниже, чем у обычных крутящихся дисков. У коллеги как-то раз померли в зеркале сразу оба SSD диска :) Нагрузка же на них совершенно одинаковые, диски обычно из одной партии => помирают примерно одновременно.
Мне кажется, эту проблему должен решать сам bcache. У SSD ведь есть алерты, что оно вот-вот умрёт? Как только такое появляется — сбрасывать все dirty страницы на диск, отключать режим writeback и кричать в консоль админу, что всё плохо и пора купить новый диск.
А вот можно ли запихнуть в bcache md-девайс — большой вопрос, он же и сам md-устройство уже. Ещё нам бы очень хотелось, чтобы можно было заюзать 1-2 SSD диска в качестве кэша для 24 обычных, которые не собраны в рейд.
У SSD вероятность спасения данных в случае зеркала сильно ниже, чем у обычных крутящихся дисков. У коллеги как-то раз померли в зеркале сразу оба SSD диска :) Нагрузка же на них совершенно одинаковые, диски обычно из одной партии => помирают примерно одновременно.
Мне кажется, эту проблему должен решать сам bcache. У SSD ведь есть алерты, что оно вот-вот умрёт? Как только такое появляется — сбрасывать все dirty страницы на диск, отключать режим writeback и кричать в консоль админу, что всё плохо и пора купить новый диск.
А вот можно ли запихнуть в bcache md-девайс — большой вопрос, он же и сам md-устройство уже. Ещё нам бы очень хотелось, чтобы можно было заюзать 1-2 SSD диска в качестве кэша для 24 обычных, которые не собраны в рейд.
А вот можно ли запихнуть в bcache md-девайс — большой вопрос, он же и сам md-устройство уже
Это не так. В bcache можно засовывать любое блочное устройство.
заюзать 1-2 SSD диска в качестве кэша для 24 обычных
Это возможно сделать штатно. Просто надо «зааттачить» столько дисков, сколько нужно и всё.
Если складывать в рейд два одинаковых из одной партии диска — то и обычные сдохнут одновременно.
и поэтому рейды сдыхают на ребилде.
> У SSD ведь есть алерты, что оно вот-вот умрёт?
если сдохнет контроллер — это произойдёт тихо и без предупреждения.
и поэтому рейды сдыхают на ребилде.
> У SSD ведь есть алерты, что оно вот-вот умрёт?
если сдохнет контроллер — это произойдёт тихо и без предупреждения.
Про контроллер — это решается 2 платами контроллерами — в двойном RAID1 — soft (между контроллерами) — hard — между дисками. Правда стоимость тогда получается в 4 раза больше, зато и надежность выше будет.
ну так писать на быстрый SSD, репортить, а уже потом в фоне сливать на медленый носитель.
читать чуть сложнее. там как фишка ляжет. часть данных может быть только на SSD и это надо учитывать
читать чуть сложнее. там как фишка ляжет. часть данных может быть только на SSD и это надо учитывать
Но как отреплеить кэш?
Пусть об этом думает разработчик кеша не вручную же вас заставляют это делать, верно?
про файлуху и ее логику он не знает ничего?
Откуда такое утверждение взялось? mkfs.xfs /dev/bcache0 как бы намекает, что драйвер в курсе.
P.S. блин, надо учиться пользоваться ссылкой «ответить» :-)
ZFS уже давно поддерживает L2ARC (cache devices) для кэшированного чтения и ZIL (log devices) для writeback-кэширования записи. Но под Linux разрабатывается подобный кэширующий механизм для всех поддерживаемых им файловых систем.
Не файловых систем, а блочных устройств. Насколько я понимаю, я могу и LVM PV таким образом кэшировать, даже если там несколько томов и в них разные файловые системы.
только в силу различия устройства ядра ОС — ZFS работает только на UNIX/Solaris-like и BSD-like.
Ога. zfsonlinux.org
Главный вопрос: какой там write amplification на SSD. В смысле, сколько операций записи проходит на SSD при каждой операции кеширования.
У flashcache (ближайший конкурент bcache) этот показатель был в районе 2-3. Что ставило местами под вопрос целесообразность кеширования (для 2к IOPS на чтение и 2k IOPS на запись, которые может выдать JBOD на 36 дисков, получается >12k IOPS на запись на SSD, что в случае не самых топовых SSD, просто сносит им крышу.)
У flashcache (ближайший конкурент bcache) этот показатель был в районе 2-3. Что ставило местами под вопрос целесообразность кеширования (для 2к IOPS на чтение и 2k IOPS на запись, которые может выдать JBOD на 36 дисков, получается >12k IOPS на запись на SSD, что в случае не самых топовых SSD, просто сносит им крышу.)
по описанию — около 3х, ага ага.
А на сколько для обычного ssd отличается запись 2 секторов за 2 операции и за одну операцию? И я не уверен, что в ядре технически просто быстро писать на диск что-то не кратное 4кб страницам.
Кстати, у вас в расчётах ошибочка:) Даже если будет write aplification = 3 то 2к записей + 2к чтений превратятся в 8к операций на SSD (а то и меньше, не все чтения туда попадут). Думаю, можно добиться write aplification = 2. Можно и 1, но тут вступает в силу вопрос из первого абзаца этого комментария.
Кстати, у вас в расчётах ошибочка:) Даже если будет write aplification = 3 то 2к записей + 2к чтений превратятся в 8к операций на SSD (а то и меньше, не все чтения туда попадут). Думаю, можно добиться write aplification = 2. Можно и 1, но тут вступает в силу вопрос из первого абзаца этого комментария.
www.fusionio.com/products/iodrive2/
модель на 768GB выдает больше 200к IOPS что для кэша самое то.
Я не думаю что пока Bcache будут использовать в продакшене активно, а если что меньше — то не думаю что там нужно будет кэшировать больше 8-12 HDD разом в дисковой корзине.
модель на 768GB выдает больше 200к IOPS что для кэша самое то.
Я не думаю что пока Bcache будут использовать в продакшене активно, а если что меньше — то не думаю что там нужно будет кэшировать больше 8-12 HDD разом в дисковой корзине.
Вы попробуйте. Test case — база данных, пишем туда много, все под кешем в writeback. Дергаем питание и смотрим что получается. Читать как работают фичи одно, а практический инструмент — немного другое.
Есть те, кто пробовал?
Есть те, кто пробовал?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
BCache готов к включению в ядро Linux