Про рандомную запись и тормоза — скорее всего это был известный и очень забавный баг. Проблема была в том, что bcache по-разному считал «грязные» блоки при работе GC и при механизме жесткого врайтбека (защита от переполнения кеша грязными блоками).
Сейчас его уже починили. Вернее как починили: при n-ном количестве бакетов с грязными блоками теперь увеличивается скорость врайтбэка.
FioSynth — это уже запускалка готовых тестов. Просто там уже есть паттерны, которые Facebook сделали на основе снятых с прода профилей нагрузки. В Linux для снятия трейсов есть blktrace, например. А вот на винде не подскажу, надо искать какой-то аналог blktrace.
при росте нагрузки начинает сильнее нагружать диск, при падении — снижает темп записи.
Ну он это делает не сразу и достаточно плавно. В каком-то из более-менее свежих ядер алгоритм, кстати, изменили и он стал менее агрессивным.
Мне кажется, что зачастую более логичным целевым параметром был бы не количество грязных данных в кэше, а задержка ввода/вывода на hdd.
Смотреть на латенси кешируемого девайса было бы интересно, да, но наверное сильно бы усложнило логику. Отталкиваются от объема кэша, потому что если он переполнится грязными блоками — всё очень резко станет плохо.
А какое решение вы рассматриваете как более приемлемое?
Интересный, кстати, вопрос. Пошел смотреть исходники bpf_ktime_get_ns(), но сходу не нашел условия, при котором она может возвращать 0. Не могу вспомнить, почему я добавил сюда эту проверку:) возможно, просто перестраховался.
Раньше везде ставили flashcache, но он, во-первых, уже не поддерживается нормально, во-вторых, хотелось кешировать запись, в том числе и последовательную. Мне у bcache очень нравится алгоритм сброса грязных блоков. Если дать постоянную нагрузку на запись, график утилизации/iops кешируемого диска выглядит как график затухающих колебаний и в итоге спрямляется. Ещё нет такой проблемы, как вытесняющий промах за счёт того как он хранит данные в кеше. Вообще удается все данные сначала залить в кеш, при этом сзади у него здоровенный hdd. На критичные баги не напарывались, в рассылках видел жуткие истории про потерю данных на последней Федоре, с ядром собранном на какой-то конкретной версии gcc.
Присоединяюсь к вопросу. В Европе везде, где я был, чай был отвратительный липтон в пакетиках, если не идти в специальную "чайную".
Сейчас его уже починили. Вернее как починили: при n-ном количестве бакетов с грязными блоками теперь увеличивается скорость врайтбэка.
Ну он это делает не сразу и достаточно плавно. В каком-то из более-менее свежих ядер алгоритм, кстати, изменили и он стал менее агрессивным.
Смотреть на латенси кешируемого девайса было бы интересно, да, но наверное сильно бы усложнило логику. Отталкиваются от объема кэша, потому что если он переполнится грязными блоками — всё очень резко станет плохо.
А какое решение вы рассматриваете как более приемлемое?
На самом деле, смотря для чего использовать. Понятно, что чем шире масштаб и выше требования к кластерам, тем больше нюансов, как и везде.
Раньше везде ставили flashcache, но он, во-первых, уже не поддерживается нормально, во-вторых, хотелось кешировать запись, в том числе и последовательную. Мне у bcache очень нравится алгоритм сброса грязных блоков. Если дать постоянную нагрузку на запись, график утилизации/iops кешируемого диска выглядит как график затухающих колебаний и в итоге спрямляется. Ещё нет такой проблемы, как вытесняющий промах за счёт того как он хранит данные в кеше. Вообще удается все данные сначала залить в кеш, при этом сзади у него здоровенный hdd. На критичные баги не напарывались, в рассылках видел жуткие истории про потерю данных на последней Федоре, с ядром собранном на какой-то конкретной версии gcc.
Да, используем.
Спасибо!