bcache vs dm-cache: Порівняння кешування на SSD в Linux

11 хв читання - 28 травня 2026 р.

hero section cover
Зміст
  • bcache проти dm-cache: кешування SSD у Linux
  • Як працює bcache
  • Як працює dm-cache
  • Режими кешування
  • bcache проти dm-cache: що вибрати
  • Висновок
Поділитися

Порівняйте bcache та dm-cache для кешування SSD в Linux. Налаштування, продуктивність, режими кешування і коли використовувати кожен з них.

bcache проти dm-cache: кешування SSD у Linux

SSD-накопичувачі швидкі, але дорогі в розрахунку на гігабайт. HDD-накопичувачі дешеві, але повільні. Linux надає два інструменти на рівні ядра для їх поєднання: bcache та dm-cache. Обидва використовують SSD як прозорий кеш перед більшим HDD, але вони відрізняються архітектурою, вимогами до налаштування та тим, де вони працюють найкраще.


 

Як працює bcache

Bcache присутній у ядрі Linux з версії 3.10 (червень 2013 року). Він працює на рівні блоків, тому сумісний з будь-якою файловою системою, що підтримує UUID.

Внутрішньо bcache використовує гібридну структуру B+ дерева/журналу. Він розділяє SSD-накопичувач на сегменти фіксованого розміру (від 128 КБ до 2 МБ), вирівняні за межами блоків стирання. Це перетворює випадкові записи на послідовні, що зменшує ампліфікацію запису та подовжує термін служби SSD. Послідовні операції вводу-виводу розміром понад 4 МБ автоматично оминають кеш, дозволяючи SSD зосередитися на випадкових моделях доступу, де він приносить найбільшу користь.

Bcache також відстежує затримку SSD у реальному часі. Якщо затримка читання перевищує 2 мс або затримка запису перевищує 20 мс, він обмежує трафік, щоб запобігти перетворенню кеш-пристрою на вузьке місце.

Налаштування

Встановіть bcache-tools, а потім відформатуйте пристрій резервного копіювання та кеш-пристрій:

make-bcache -B /dev/sdb          # format HDD as backing device
make-bcache -C /dev/sdc          # format SSD as cache device
echo <UUID> > /sys/block/bcache0/bcache/attach   # attach cache

Налаштування під час роботи здійснюється через /sys/block/bcache<N>/bcache/ інтерфейс sysfs, де ви можете налаштувати режими кешування, порогові значення послідовного вводу-виводу та цільові значення затримки. Для масивів RAID використовуйте --data-offset для вирівнювання з шириною смуги.

Підступ: налаштування є руйнівним. Обидва пристрої потрібно відформатувати як цілі bcache, тому ви не можете додати bcache до існуючої файлової системи, не стерши її спочатку. Розмір пристроїв bcache також не можна змінити після створення.

Продуктивність

Консолідація запису bcache забезпечує високі показники випадкового запису. У тестах продуктивність досягала приблизно 18 500 випадкових операцій запису 4K на секунду (IOPS) порівняно з 12 200 IOPS на самому SSD. Пропускна здатність випадкового читання може досягати приблизно 1 000 000 IOPS за наявності відповідного обладнання.

Для зашифрованих робочих навантажень слід накласти dm-crypt на /dev/bcache<N> пристрою, а не шифрувати базові диски окремо. Зазвичай це дає кращі результати, оскільки bcache все ще може консолідувати записи перед шифруванням.

Як працює dm-cache

dm-cache — це ціль Device Mapper, яка розміщується над існуючим логічним томом. Вона використовує три підпристрої: вихідний пристрій (HDD), кеш-пристрій (SSD або NVMe) та пристрій метаданих, який відстежує розташування блоків та стан змін. Політика кешування за замовчуванням — smq (Stochastic Multi-Queue), яка ідентифікує «гарячі» дані у змішаних робочих навантаженнях.

Ключова перевага: dm-cache можна накласти на активний том LVM без знищення існуючих даних. Ви також можете змінювати його розмір за допомогою стандартних команд LVM.

Налаштування з LVM

Практичний спосіб налаштування dm-cache — через lvmcache. Ручна dmsetup налаштування можливе, але схильне до помилок і не зберігається після перезавантаження. Підхід LVM:

  1. Створіть фізичні томи (PV) як на HDD, так і на SSD.
  2. Додайте обидва PV до однієї групи томів (VG).
  3. Створіть три логічні томи: один для резервних даних (HDD), один для кешу (SSD), один для метаданих (SSD).
  4. Об'єднайте логічні томи кешу та метаданих у пул кешу:
    lvconvert --type cache-pool --poolmetadata <meta_lv> <cache_lv>
  5. Підключіть пул до джерела:
    lvconvert --type cache --cachepool <pool_lv> <data_lv>

Одне зауваження: підключіть файлову систему за її /dev/mapper/ шляху, а не за UUID. Монтування за UUID може обійти рівень кешу та звернутися безпосередньо до вихідного пристрою.

Продуктивність та пам'ять

У режимі запису з відстрочкою при навантаженні Zipf із співвідношенням читання/запис 90/10 dm-cache досяг швидкості читання близько 193 МБ/с і швидкості запису приблизно 21 МБ/с. В іншому тесті кешування 100-гігабайтного HDD з 10-гігабайтним розділом NVMe збільшило випадкові операції запису IOPS зі 118 до 798.

Компромісом є пам'ять. Накладні витрати dm-cache на метадані залежать від розміру блоку. Розмір блоку 512 байт може споживати понад 16 ГБ оперативної пам'яті на 100 ГБ кешу. Збільшення цього значення до 4096 байт знижує використання пам'яті до приблизно 2 ГБ на 100 ГБ. Виберіть розмір блоку, близький до середнього розміру вводу-виводу (64 КБ — це розумна відправна точка), і переконайтеся, що він є кратним 64 секторам (32 КБ) у діапазоні від 32 КБ до 1 ГБ.

Метадані очищаються при кожному записі FLUSH або FUA, або принаймні раз на секунду. Для забезпечення високої доступності створіть дзеркало пристрою метаданих, щоб уникнути єдиної точки відмови.

Режими кешування

І bcache, і dm-cache підтримують однакові основні режими кешування. Вибір режиму впливає як на продуктивність, так і на безпеку даних.

РежимЯк це працюєШвидкістьРизик
WritethroughЗаписи надходять одночасно як на SSD, так і на HDDТільки прискорення читанняНизький. На HDD завжди зберігаються актуальні дані.
Зворотний записЗаписи спочатку надходять на SSD, а потім скидаються на HDDПідвищення швидкості читання та записуВищий. Збій SSD до зливу означає втрату даних.
Обхідний запис / ПропускЗаписи повністю обходять кешТільки прискорення читання, зменшення зносу SSDНизький. На HDD завжди є актуальні дані.

Writethrough є безпечним варіантом за замовчуванням для обох інструментів. Writeback є швидшим, але створює реальний ризик: якщо SSD вийде з ладу, утримуючи нескинуті дані, ці дані будуть втрачені, а файлова система може бути пошкоджена. Використовуйте writeback лише тоді, коли у вас є дублюючі SSD або ви можете змиритися з періодичною втратою даних.

bcache проти dm-cache: що вибрати

Факторbcachedm-cache
Налаштування на існуючих данихЗнищення даних (потрібне очищення)Без втрати даних (онлайн-конвертація)
Зміна розміруНе підтримуєтьсяПідтримується через LVM
Оптимізація випадкового записуСильна (консолідація послідовного запису)Стандартна
Обхід послідовного вводу-виводуАвтоматичний (>4 МБ)Управління за допомогою політики smq
Навантаження на пам'ятьНизька (дерево B+)Вища (залежить від розміру блоку)
МетаданіНа кеш-пристроїНа окремому пристрої, може бути дзеркально відображено

Використовуйте bcache, коли ви будуєте нову систему з нуля і хочете отримати найкращу продуктивність випадкових операцій вводу-виводу. Це кращий вибір для робочих навантажень з великим обсягом запису, таких як бази даних і сховища віртуальних машин, а також для масивів RAID 6, де втрати продуктивності при випадковому записі є значними.

Використовуйте dm-cache, якщо вам потрібно додати кешування до сервера, який вже працює. Інтеграція з LVM означає, що ви можете підключити кеш без простою або міграції даних. Це кращий варіант для робочих навантажень з великим обсягом читання та середовищ, де потрібна гнучкість для зміни розміру або переконфігурації сховища на льоту.

Висновок

Обидва інструменти вирішують одну й ту саму проблему, але підходять для різних ситуацій. Bcache — це найкращий вибір для нових систем. dm-cache — це практичний вибір для існуючих систем LVM. Що б ви не обрали, почніть з режиму writethrough, доки не переконаєтеся в надійності вашого SSD, а потім перейдіть на writeback, якщо вам потрібна продуктивність запису.

Якщо вам потрібні виділені сервери з конфігураціями кешування SSD, ознайомтеся з варіантами виділених серверів від FDC.

Блог

На цьому тижні

Більше статей
XDP та eBPF для обробки пакетів у Linux

XDP та eBPF для обробки пакетів у Linux

Як XDP і eBPF обробляють мільйони пакетів в секунду на рівні драйверів мережевих карт. Бенчмарки, випадки використання DDoS, налаштування інструментарію та вимоги до апаратного забезпечення.

14 хв читання - 27 травня 2026 р.

Чому важливо мати потужний і нелімітований VPS

3 хв читання - 9 травня 2025 р.

Більше статей
background image

Маєте запитання або потребуєте індивідуального рішення?

icon

Гнучкі варіанти

icon

Глобальне охоплення

icon

Миттєве розгортання

icon

Гнучкі варіанти

icon

Глобальне охоплення

icon

Миттєве розгортання