Комментарии 28
Как оно относится к жесткой остановке работы, когда на SSD остаётся масса dirty-блоков?
Bcache не различает жесткую остановку и обычную. Dirty блоки останутся целы и невредимы и работа с кэшем продолжится из последнего состояния. Из документации:
Bcache goes to great lengths to protect your data — it reliably handles unclean shutdown. (It doesn't even have a notion of a clean shutdown; bcache simply doesn't return writes as completed until they're on stable storage).
Это для writethrough и так вроде все делают в этом режиме.
WriteBack, скорее всего, уничтожит базу. Вот есть блочное устройство с кешем, есть файлуха. На кэше блоки свои, у файлухи свои. Вырубается питание. Все, что было в памяти и не успело упасть в кэш на ssd — пропало. Так? Как теперь кэш, который ничего не знает про файловую систему и ее состояние, поймет, какие блоки где dirty? Надо все делать dirty, либо какойто журнал вести, что опять сильно снижает эффективность такого кэша.
WriteBack, скорее всего, уничтожит базу. Вот есть блочное устройство с кешем, есть файлуха. На кэше блоки свои, у файлухи свои. Вырубается питание. Все, что было в памяти и не успело упасть в кэш на ssd — пропало. Так? Как теперь кэш, который ничего не знает про файловую систему и ее состояние, поймет, какие блоки где dirty? Надо все делать dirty, либо какойто журнал вести, что опять сильно снижает эффективность такого кэша.
А зачем использовать writethrough? Есть pagecache, который работает вполне себе сам. Память стоит не слишком дорого.
Лично я вижу смысл применения только в режиме writeback, потому и интересуюсь.
ToSHiC однажды высказывал мысль, что можно хранить карту dirty-блоков на самом SSD, тогда будет большой write amplification, но безопасное резкое отключение питания.
Лично я вижу смысл применения только в режиме writeback, потому и интересуюсь.
ToSHiC однажды высказывал мысль, что можно хранить карту dirty-блоков на самом SSD, тогда будет большой write amplification, но безопасное резкое отключение питания.
Кэш с dirty данными работает как база данных. Для каждого блока сохраняются его метаданные и он сам. После этого запись считается выполненной. Так что при выключении питания информация о том какой блок dirty, а какой нет — останется. Так же останется информация какие блоки, каким данным на диске соответствуют.
Я про writeback.
Осталось понять, как эти метаданные кэша связаны с файлухой и уже ее журналом. Вот свет появился, акей, эти блоки надо записать, а эти уже dirty. А на файлухе другая картина уже и она хочет совсем другого, чем ей дает записать кэш. Каша будет, я это наблюдал не раз. Нет батарейки — прощайте данные. Это наверное работает, но под нормальной нагрузкой под тысячу рпс на бекенд, пишущий в базу постгреса, у меня в 10 случаях из 10 данные превращались в кашу. Это выглядит, как, напрмер, кусок сислога посреди файла с таблицей. Или кусок таблицы в другой таблице. Все, куда была интенсивная запись, все перемешано.
Осталось понять, как эти метаданные кэша связаны с файлухой и уже ее журналом. Вот свет появился, акей, эти блоки надо записать, а эти уже dirty. А на файлухе другая картина уже и она хочет совсем другого, чем ей дает записать кэш. Каша будет, я это наблюдал не раз. Нет батарейки — прощайте данные. Это наверное работает, но под нормальной нагрузкой под тысячу рпс на бекенд, пишущий в базу постгреса, у меня в 10 случаях из 10 данные превращались в кашу. Это выглядит, как, напрмер, кусок сислога посреди файла с таблицей. Или кусок таблицы в другой таблице. Все, куда была интенсивная запись, все перемешано.
В том случае, в котором был бы фэйл на обычном HDD — будет фэйл и у bcache. Как я понимаю, дополнительной угрозы данным bcache не вносит. Файловая система не видит отдельных секторов диска, для нее диск — это bcache. А bcache делает работу записи такой же надежной как и запись на голый HDD, потому как операции записи возвращаются, когда данные и их метаданные уже сохранены на SSD.
читал, что толку от SSD ZIL в ZFS намного меньше по сравнению с добавлением оперативки
хотелось бы повысить скорость random write, для read то поди и линукс ядро нормально справится, да и ZFS ARC вроде нормальный
а имеет ли смысл для увеличения random write IOPs прикрутить bcache к ZFS ZVol (кусочек пула в качестве блочного устройства), не ухудшится ли надежность при выдергивании SSD или 220В?
хотелось бы повысить скорость random write, для read то поди и линукс ядро нормально справится, да и ZFS ARC вроде нормальный
а имеет ли смысл для увеличения random write IOPs прикрутить bcache к ZFS ZVol (кусочек пула в качестве блочного устройства), не ухудшится ли надежность при выдергивании SSD или 220В?
Меня вот вопрос интересует а без bcache устройства доступ получить ко всему этому можно?
bcache — это просто устройство через которое мы работаем с HDD. Он появляется когда подключенный кэш инициализировался, если кэш не был подключен, как в начальном этапе настройки — bcache появится сразу. Если с SSD диском случилось что-то плохое и bcache не появился — можно вручную заставить bcache стартовать (все dirty данные из кэша, ясное дело, будут утеряны):
Или я неправильно понял вопрос? :)
echo 1 > /sys/block/sdb/bcache/running
Или я неправильно понял вопрос? :)
Правильно. А то вот в этой схеме по сравнению с flashcache меня сильно смущал момент, что надо форматировать отдельно.
т.е. если поверх bcache смонтировать ext4 с опциями journal_checksum,data=journal (хотя, наверно, достаточно журналировать метаданные)
начать записывать много мелких файлов и и дернуть SSD или питание,
то файловая система не порушится и все, что было записано до подключения SSD и bcache останется (если специально не стирать)?
начать записывать много мелких файлов и и дернуть SSD или питание,
то файловая система не порушится и все, что было записано до подключения SSD и bcache останется (если специально не стирать)?
А чем Bcache отличается от Flashcache, разработанный Facebook? Насколько мне известно, только Flashcache сейчас готов к продакшну.
тоже очень любопытно, хотя ни один пока не использовал
Тесты показывают, что Flashcache проигрывает bcache в скорости.
Около года используем FlashCache в продакшене под postgresql базами, отзывы только положительные. Отличия:
Flashcache основан на devoce-mapper поэтому перед тем как начать его использовать, нужно «слепить» гибридный dm-том из имеющегося тома и SSD-тома/раздела/диска. И потом это гибридное устройство монтировать и использовать.
Bcache (как и EnhanceIO) это отдельный блочный драйвер, не использующий device-mapper слой.
Оба отличаются подходом в создании томов (в flashcache мне как-то показалось проще это устроено, bcache показался непривычным flashcache… а enhanceio вобще показался сказкой, но он медленный это правда + пару раз ловил kernel panic).
Flashcache основан на devoce-mapper поэтому перед тем как начать его использовать, нужно «слепить» гибридный dm-том из имеющегося тома и SSD-тома/раздела/диска. И потом это гибридное устройство монтировать и использовать.
Bcache (как и EnhanceIO) это отдельный блочный драйвер, не использующий device-mapper слой.
Оба отличаются подходом в создании томов (в flashcache мне как-то показалось проще это устроено, bcache показался непривычным flashcache… а enhanceio вобще показался сказкой, но он медленный это правда + пару раз ловил kernel panic).
Откуда информация о включении EnhanceIO в 3.10? В LKML появились патчи с запросом о включении, но мейнтейнеры затребовали обоснование и конкретные результаты тестов, после чего процесс включения пока заглох.
вы ускоряете в основном запись или чтение?
насколько запись и чтение рандомные?
какое соотношение размеров SSD и HDD?
какие прогнозы выжиываемости при внезапной смерти SSD?
Я о том, насколько оно лучше, чем просто заменить старый винчестер на SSD.
насколько запись и чтение рандомные?
какое соотношение размеров SSD и HDD?
какие прогнозы выжиываемости при внезапной смерти SSD?
Я о том, насколько оно лучше, чем просто заменить старый винчестер на SSD.
В основном я ускоряю чтение, данные редко меняются.
Настолько на сколько рандомно чтение при работе с большой базой данных.
HDD, как я писал, 2Tb и SSD 120Gb
Если не использовать writeback кэширования — никаких проблем быть не должно. Если умрет кэш с dirty данными, будет конечно хуже. Я посматриваю на smart показатели SSD диска, чтобы смерть не стала неожиданной. Опять таки работать с важными данными и не делать бэкап было бы глупо. HDD тоже умирают время от времени.
SSD на 512Gb стоит несколько дороже, чем такое вот решение. Да и время жизни SSD с базой, мне кажется, будет меньше чем у SSD c writetrough кэшем той же базы.
Настолько на сколько рандомно чтение при работе с большой базой данных.
HDD, как я писал, 2Tb и SSD 120Gb
Если не использовать writeback кэширования — никаких проблем быть не должно. Если умрет кэш с dirty данными, будет конечно хуже. Я посматриваю на smart показатели SSD диска, чтобы смерть не стала неожиданной. Опять таки работать с важными данными и не делать бэкап было бы глупо. HDD тоже умирают время от времени.
SSD на 512Gb стоит несколько дороже, чем такое вот решение. Да и время жизни SSD с базой, мне кажется, будет меньше чем у SSD c writetrough кэшем той же базы.
Возьму ваш опыт на заметку. От себя добавлю, что неплохой прирост производительности можно получить, если все же докупить несколько хардов и раскидать на них таблицы, логи и индексы (каждому — свой хард).
> Хочешь скачать — качай репозиторий (700Мб где-то).
На заметку:
На заметку:
git clone --depth 1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускоряем базу данных. Bcache