bcache vs. dm-cache

Testowałem bcache około roku temu na moim zapasowym serwerze i działało to całkiem nieźle. Ale od tego czasu, z każdym nowym kernelem pojawiały się nowe, często krytyczne problemy. Na liście malingowej nawet sugerowano, żeby bcache oznaczyć z powrotem jako ‚experimental’. Po jakimś czasie dałem sobie spokój z tym i zacząłem czekać na coś bardziej stabilnego i prostego do konfiguracji. W tym czasie w kernelu było już dm-cache, ale wymagało dosyć karkołomnych wywołań dmsetup z różnymi ręcznie obliczonymi numerkami – idealny sposób na utratę danych 🙂 Bardziej przyjazny interfejs do zarządzania był dopiero w planach jako część LVM2.

Na dzień dzisiejszy, LVM2 ma już wszystkie funkcje potrzebne do zarządzania dm-cache, więc nadszedł czas dać mu szansę 🙂

Podsumowując moje dotychczasowe doświadczenie o oboma rowiązaniami:

• bcache
  • + całkiem dobra dokumentacja jak działa cache, opis interfejsu do monitorowania, formatu na dysku i co zrobić w wypadku problemów
  • + cache działa bezpośrednio na poziomie urządzenia blokowego, więc można tak przyspieszyć cały fizyczny dysk bez udziału lvm-a, również w ten sposób można keszować wszystkie logiczne wolumeny jeżeli dysk z bcache potraktujemy jako fizyczny wolumen dla lvm-a
  • + nie ma problemów ze zmianą rozmiarów wolumenów na lvm-ie, bo bcache jest pod spodem
  • + można zmieniać wiele parametrów cache ‚w locie’ włącznie z polityką writethrough/writeback
  • – nie można zmienić w locie urządzenia z keszowanego na niekeszowany (i odwrotnie)
  • – niestabilny
  • ~ nie wymaga lvm-a do działania
• dm-cache
  • + stabilny
  • + łatwy do konfiguracji
  • + można bez problemu przekonwertować dowolny wolumen lvm-a na wspierany przez cache i odwrotnie
  • – jeden wolumen z cache dla jednego logicznego wolumenu jaki chcemy przyśpieszyć, więc jak mamy więcej wolumenów, to też potrzeba więce kawałków cache – w porównaniu do współdzielonego cache tracimy miejsce
  • – bardzo pobieżna dokumentacja – wystarczająca do konfiguracji, ale praktycznie bez żadnych informacji jak i czy można zmieniać jakieś parametry dla cache, lub jak to monitorować
  • – zmiana wielkości logicznego wolumenu musi odbyć się przez pozbawienie go cache, zmianę i założenie cache od nowa – tracimy wtedy całą zawartość cache
  • ~ jest częścią lvm-a

Wymagania

Czas wrócić do Slackware. Obecnie najnowszą stabilną wersją jest 14.1, więc wszystko co dalej opiszę będzie bazować na niej.

Świeży kernel

Dystrybucyjny kernel (3.10.17) jest trochę za stary dla dobrej pracy cache, więc lepiej wziąć coś z serii co najmniej 3.14. Można skompilować sobie samemu lub pobrać świeższy z drzewa slackware-current w którym obecnie jest 3.14.33.

Świeży LVM2

Wersja LVM2 w Slackware 14.1 jest prawie ostatnią wersją BEZ wparcia dla dm-cache, więc tu obowiązkowo trzeba ściągnąć i skompilować świeżą. Dla pełnego wsparcia potrzeba jeszcze thin-provisioning-tools z narzędziami typu fsck dla dm-cache.

Sposób trudny (kompilacja wszystkiego samemu)

1. Ściągnąć źródła pakietu LVM2 z ftp://ftp.osuosl.org/pub/slackware/slackware64-14.1/source/a/lvm2/
2. Ściągnąć świeższą wersję żródeł LVM2 z ftp://sources.redhat.com/pub/lvm2/releases/LVM2.2.02.116.tgz
3. Ściągnąć thin-provisioning-tools z https://github.com/jthornber/thin-provisioning-tools/archive/v0.4.1.tar.gz i zapisać je jako thin-provisioning-tools-0.4.1.tar.gz
4. Ściągnąć mój patch na SlackBuild z https://majek.sh/dm-cache/slackware-lvm2-dm-cache.patch i zaaplikować do w latalogu lvm2:
   patch -p0 < slackware-lvm2-dm-cache.patch
5. Zbudować nowy pakiet z lvm2:
   sh lvm2.SlackBuild
6. Zaktualizować pakiet lvm2 nowym, który powinien być w katalogu /tmp
7. Jeżeli chcemy użyć cache na partycji z systemem (i używamy lvm-a oraz initrd), to najlepiej zaaplikować mój kolejny patch na mkinitrd i przebudować initrd.
   Łatka: slackware-mkinitrd-dm-cache.patch.
   Zastosowanie łatki:
   cd /sbin
   patch -p0 < /somewhere/slackware-mkinitrd-dm-cache.patch
8. Używać 🙂

Sposób dla leniwych 🙂

Ściągnij mój gotowy pakiet z lvm2 i zainstaluj/uaktualnij obecny. Dodatkowo możesz też potrzebować łatkę na mkinitrd (zobacz punkt 7 powyżej).

Konfiguracja

Tworzenie cache jest całkiem dobrze opisane w man lvmcache.
Szybkie ‚howto’, zakłądając że mam grupę nazwaną vg_group, dysk na cache (ssd) to /dev/sdb1 i wolumen do przyspieszenia, to lv_home.

1. Na początek, dysk ssd na cache musi być częścią volume grupy:
   vgextend vg_group /dev/sdb1
2. Tworzymy wolumen na cache na szybkim dysku (domyślnym trybem jest writethrough – bezpieczniejszy, ale wolniejszy, więc dla writeback trzeba dodać odpowiednią opcję):
   lvcreate --type cache-pool --cachemode writeback -L 10G -n cacheX vg_group /dev/sdb1
3. Łączymy wolumen cache z wolumenem do przyspieszenia:
   lvconvert --type cache --cachepool vg_group/cacheX vg_group/lv_home
4. Cieszymy się 🙂