LINUX.ORG.RU

bcache vs dm-cache vs enhanceIO vs flashcache (SSD Cache) - что выбрать?

 , , , ,


0

3

Всем привет.

Есть рабочая система с Raid 1 на 2ух HDD.

Есть SSD на 120 гб, который завалялся.

Задача: все данные на Raid 1 оставить без изменений, прицепить кэш. Получить максимальный IOPS.

На Raid 1 виртуалки (KVM) и контейнеры (LXC).

Bcache как я понял - «протух» и с недавних пор идёт в составе bcachefs. Требует форматирования ФС.

dm-cache сложен в настройке и требует предварительного подсчета размера метаданных.

enhanceIO - судя по бенчмаркам самый перспективный, но последние патчи были в 2017ом.

flashcache - ?

Хотелось бы услышать более развернутый аргумент, чем мой. Может есть что-то ещё?

★★

1. Bcache как был частью ядра, так и остался. Протухать там особо нечему, просто главный разраб пилит ФС. Да, требует форматирования

2. dm-cache — в принципе всё верно, но он стабилен, опять же есть в ядре, юзается lvm-cache'ом к примеру. Так что если что придётся покурить маны.

3. enhanceIO — да, он интересный и самобытный проект. Сейчас есть активный форк — https://github.com/lanconnected/EnhanceIO который вроде как даже пилиться. Последнее изменение были 4 дня назад.

chaos_dremel ★★ ()
Ответ на: комментарий от chaos_dremel

Спасибо за развернутый ответ. Можете что-то по поводу flashcache дополнить? По ману показался очень простым.

BitSum ★★ ()
Ответ на: комментарий от BitSum

flashcache это предшественик enhanceIO. Собственно enhanceIO сильно шагнул вперёд от него. Активных форков его я не знаю и даже года три назад, когда я прицельно смотрел кеши, он не вызывал доверия в плане стабильности и починки багов. Более того, я очень сомневаюсь, что его можно завести на новых ядрах.

chaos_dremel ★★ ()
Ответ на: комментарий от chaos_dremel

Прошу помощи ещё с несколькими моментами:

fdisk -l

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe1eeb149

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1  *     2048 976771071 976769024 465.8G fd Linux raid autodetect


Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00040e2a

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1        2048 976771071 976769024 465.8G fd Linux raid autodetect


Disk /dev/sdc: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md0: 465.7 GiB, 499971522560 bytes, 976506880 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd9852cef

Device     Boot     Start       End   Sectors   Size Id Type
/dev/md0p1           2048 936941567 936939520 446.8G 83 Linux
/dev/md0p2      936943614 976504831  39561218  18.9G  5 Extended
/dev/md0p5      936943616 976504831  39561216  18.9G 82 Linux swap / Solaris

как создаю:

~/EnhanceIO# /usr/local/sbin/eio_cli create -d /dev/sda1 -s /dev/sdc -m wt -b 4096 -c sda1

/dev/sdc - SSD

/dev/sda1 непосредственно сам Raid 1 средсвами mdadm.

Статистика есть (cat /proc/enhanceio/sda1/stats sda1)

ssd_reads                          3720
ssd_writes                      1307100

Правильно ли?

BitSum ★★ ()
Последнее исправление: BitSum (всего исправлений: 3)
Ответ на: комментарий от BitSum

Ранее либа компилировалась за 1 час, теперь 5. Нормально так заоптимизировал хДД

BitSum ★★ ()
Ответ на: комментарий от BitSum

Sda это диск, sda1 — раздел на нём, который входит в рейд. Рейд средствами mdadm это md0, на котором есть ещё разделы с какой-то ФС. Я бы делал кеш именно на раздел, например /dev/md0p1, если там поверх раздела не натянуто ещё что-то (LVM например). Короче говоря делать кеш надо для наиболее отдалённой от железа сущности

chaos_dremel ★★ ()
Последнее исправление: chaos_dremel (всего исправлений: 1)

bcache. Зрелый и стабильный проект.

Любую технологию ты можешь проверить в VirtualBox, например. Под «можешь» я имею ввиду, что так и надо сделать, что бы не похерить данные и потренироваться. На всех перечисленных тобой способах. Просто создай виртуальный диск на hdd а другой на ssd, настрой, проверь и померь. Результаты будут конечно примерные, но должны показать относительный выигрыш

Deleted ()

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

avb ()
Ответ на: комментарий от chaos_dremel
 /usr/local/sbin/eio_cli create -d /dev/md0p1 -s /dev/sdc -m wt -b 4096 -c sda1

?

Cache Name       : sda1
Source Device    : /dev/md0p1
SSD Device       : /dev/sdc
Policy           : lru
Mode             : Write Through
Block Size       : 4096
Associativity    : 256
ENV{MD_UUID}=="", ENV{MD_DEV_UUID}=="", ATTR{partition}=="1"
ENV{ID_SERIAL}=="INTEL_SSDSC2BW240A3L_CVCV2280020K240CGN", ENV{DEVTYPE}=="disk"
Cache created successfully

А смутило меня это:

ENV{MD_UUID}=="", ENV{MD_DEV_UUID}=="", ATTR{partition}==«1»

BitSum ★★ ()
Ответ на: комментарий от Deleted

Проблема bcache в том, что под него придется отформатировать файловую систему, на которой данные.

BitSum ★★ ()
Ответ на: комментарий от BitSum

Не имеет значения, тем более, что передаётся, судя по команде, всё устройство и кеш юзает его по своим алгоритмам. По идее ext4 там уже нет)

chaos_dremel ★★ ()
Ответ на: комментарий от chaos_dremel

Как правильно удалять/отключать кэш?

При создании кэша что-то помимо

/usr/local/sbin/eio_cli create -d /dev/md0p1 -s /dev/sdc -m wt -b 4096 -c sda1
требуется?

Посмотрел статью на хабре. Что-то она совсем не актуальна.

p.s. Машину не жалко, но файлуха разваливается уже во второй раз после «reboot».

В последний раз было примонтировано устройство с которого копировались данные на /dev/md0p1. Процесс копирования был убит вручную. Устройство не было размонтировано. Сами же данные, которые были скопированы были удалены. Выполнен ребут.

BitSum ★★ ()
Последнее исправление: BitSum (всего исправлений: 1)
Ответ на: комментарий от BitSum

Сам кэш удалял так:

disable/delete.

Никаких команд на синхронизацию или сброс с кэша не нашёл.

BitSum ★★ ()
Ответ на: комментарий от BitSum

Ошибку понял.

https://wiki.archlinux.org/index.php/EnhanceIO

This will use the default options which are safe, if you want to enhance speed even further you might want to add -m wb to enable WriteBack mode instead of WriteThrough. This might put data itegrity at risk though.

The cache drive is persistent now, which means even after a reboot it will still be used. If you want to deactive it first set the cache into read-only mode to not lose any yet unwritten blocks

# eio_cli edit -c my_first_enhanceio -m ro

BitSum ★★ ()
Ответ на: комментарий от chaos_dremel

Нет-нет, у меня проблемы с write through, но как я понял - кэш обязательно нужно переводить в рид онли перед удалением или отключением.

Первое предложение было лишним, но арч вики явно раскрывает то, что команда выше может быть сокращена до:

/usr/local/sbin/eio_cli create -d /dev/md0p1 -s /dev/sdc -c sda1

тк по стандарту уже Write Through с нужным блоком.

BitSum ★★ ()
Последнее исправление: BitSum (всего исправлений: 8)
Ответ на: комментарий от BitSum

Не успел дописать.

Также для безопасности перед удалением/отключением нужно получить значение 0

grep nr_dirty /proc/enhanceio/enchanceio_test/stats

BitSum ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.