mOlind Nov 14 2013 at 17:57

Сравнение bcache и btier

3 min

11K

Configuring Linux*System administration*

+23

Comments 14

amarao Nov 14 2013 at 18:43

Спасибо. Про btier я не слышал, а штука крайне интересная. Поставил в список технологий на изучение.

datacompboy Nov 14 2013 at 20:29

ждём нормального обзора и тестов :_)

ToSHiC Nov 14 2013 at 18:48

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

mOlind Nov 14 2013 at 19:03

Объем btier = ssd + hdd как на крайней правой схеме в начале статьи. Можно записывать файлы без ограничений по размеру. Хоть в 2 раза больше чем ssd. Только вы не можете насильно сказать системе что должно быть на ssd, а что нет. Она сама решает.

ToSHiC Nov 14 2013 at 19:07

Запись не всегда всегда сначала на SSD падает?

mOlind Nov 14 2013 at 19:32

Четкого ответа на этот вопрос у меня нет. Есть только практические наблюдения: У btier есть такой параметр как allocated size — обьем блоков, в которые файловая система уже что-то писала. Когда этот allocated size рос — он записывал на SSD в первую очередь. Когда я почистил файлы на диске — allocated size остался прежним. И новые файлы писались уже без роста allocated size. В моем случае все они попали на hdd.

blabla Nov 14 2013 at 21:41

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

А как же кэш на запись? Ведь кэшируется не только чтение, но и запись, а запись более дорогая операция, так как кэш самого жесткого диска может для нее не использоваться(так как энергозависим), а SSD может использоваться, так как энергонезависим.

mOlind Nov 14 2013 at 23:48

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

ZyXI Nov 14 2013 at 23:54

В кэше не может быть несколько SSD дисков.

В первой ссылке по запросу bcache HOWTO утверждается, что как местом расположения кэша, так и местом расположения HDD может быть любое блочное устройство. Любое — это значит, что вы можете поставить там RAID0 из SSD, LVM раздел или даже другую пару устройств под управлением bcache (хотя это и не имеет смысла).

Другой вопрос, что именно надо поставить, чтобы уменьшить время доступа (в интернете утверждают, что кэшировать на RAID0 из SSD не имеет смысла, так как это увеличит задержки; не знаю, насколько можно им верить). Но тот же LVM может склеивать диски последовательно ⇒ не увеличивая время доступа. Хотя, конечно, если бы данные по дискам раскидывал сам bcache, то можно было бы оптимизировать алгоритм.

mOlind Nov 15 2013 at 00:00

Да, все верно. Но это обходные пути, которые надо подключать к bcache вместо прямого доступа к диску. У bcache в документации сказано, что они работают с cache set-ами. Но на текущем этапе развития проекта в cache set-e может быть только один SSD.

alz Nov 15 2013 at 02:18

Меня bcache больше всего привлекает реакцией на сценарий «ssd накрылся»

mOlind Nov 15 2013 at 14:06

Есть у меня цитата по этому поводу из свежего лога:

[236703.540244] EXT4-fs warning (device bcache0): ext4_end_bio:332: I/O error writing to inode 44040362 (offset 0 size 0 starting block 126647204)
[236703.560457] EXT4-fs warning (device bcache0): ext4_end_bio:332: I/O error writing to inode 44040510 (offset 0 size 0 starting block 140103448)
[238784.354788] bcache: cached_dev_detach_finish() Caching disabled for sdc6
[238784.462924] bcache: cache_set_free() Cache set 4b7f2878-bb7f-4f43-ab6b-03611d38b604 unregistered

Со стороны приложений падение кэша осталось незамеченым.

mOlind Dec 30 2013 at 19:51

А закончилось тем, что собрал RAID0 из 3х ssd. Теперь никаких затыков с доступом к файлам. :)

gmelikov May 21 2018 at 19:03

Будьте аккуратны, в btier много проблем, поверхностное ревью кода btier.

Show the best of all time