Migracje do bcache



Natywnego użycia SSD jako pamięci podręcznej (coś jak ZIL czy L2ARC) w btrfs się nie doczekałem, mimo planów sprzed 4 lat. Postanowiłem więc zastosować bcache, który wydaje się już stabilny (miał na dorośnięcie sześć lat), chociaż jego autor wpadł ostatnio na dziwny pomysł przerobienia go na system plików.

bcache ma jeden spory minus: wymaga specjalnego sformatowania dysku, który ma przyspieszać (taki dm-cache potrafi się dołączyć na żywca). Trzeba więc jakoś przenieść dane.

Stan wyjściowy

Celem była sensowniejsza konfiguracja pamięci masowej na moim domowym serwerku. Jest to maszynka wszystkomająca, czyli jest tam mój katalog domowy, archiwum i serwer poczty, bazy danych, backupy zdjęć z wyjazdów, skany dokumentów, blog, stronka www, dane multimedialne, maszyny wirtualne i przeróżne inne dane. Do tej pory zaorganizowane tak:

http://dżogstaff.pipebreaker.pl/2016.05.25-stan-wyjściowy.svg

Na dysku SSD trzymałem większośc /var i katalogi domowe. Nie widzę finansowego sensu trzymania wszystkiego na SSD.

Skorzystanie z bcache to wetknięcie w tę jengę kolejnego klocka. A nawet dwóch. Pojawiają się dwie możliwości umieszczenia nowej warstwy.

Opcja 1 – bcache na szczycie

Czyli tuż pod systemem plików:

http://xn--dogstaff-33b.pipebreaker.pl/2016.05.25-opcja1.svg

Zalety: - powinno być szybciej, bo cache na SSD nie jest szyfrowany w tym rozwiązaniu

Ale również wady: - cache nie jest szyfrowany; co prawda wydaje mi się, że będzie tam sieczka, ale zawsze jest ryzyko odzyskania mniejszych plików

Opcja 2 - bcache na spodzie

Umieszczenie warstwy bcache tuż nad dyskami wyglądałoby tak:

http://xn--dogstaff-33b.pipebreaker.pl/2016.05.25-opcja2.svg

Zalety: - układ wydaje mi się bardziej estetyczny, logiczniejszy

Wady: - więcej ruchomych elementów przy migracji – trzeba jeszcze zadbać o LUKSa na dm-crypt

W obu opcjach korzystam z tego, że jeden cache może obsługiwać dowolną liczbę urządzeń. Dzięki temu nie musiałem dzielić mojego SSD na kolejne partycje.

(opcji trzeciej miszmasz na krzyż nie ma co omawiać)

Plan i migracja

Planowałem wykorzystać właściwości RAID1 i migracji dokonać poprzez: # oznaczenie jednego z dysków jako popsuty # przeformatowanie pod bcache, przeLUKSowanie tego dysku # dołączenie gotowego dysku z powrotem do puli btrfs # odbudowa RAID1 # powtórka zabawy z drugim dyskiem # przegranie /var i ~ # podpięcie zwolnionego dysku SSD jako cache

Zestawiłem sobie na maszynie wirtualnej identyczną konfigurację i zacząłem testy. Poległem na punkcie 1.. btrfs nie ma możliwości grzecznego popsucia dysku (skandal!). Można co najwyżej wyrwać dysk z maszyny i szybko wyczyścić.

Nie chcąc tracić za dużo czasu (jakby coś nie poszło, to odwinięcie danych z backupu trochę jednak trwa), zacząłem szukać innej drogi. Wszystkie luźne dyski w pracy użyłem do postawienia małego klastra Ceph (fajna zabawka swoją drogą), nie miałem pomysłu skąd wziąć tymczasowe kilka terabajtów.

Postanowiłem sprawdzić konwerter o jakże nudnej nazwie blocks. I to był strzał w dziesiątkę. blocks potrafi przesunąć nagłówek LUKS i umieścić przed nim nagłowek bcache, nie ruszając danych. Kilka testów i dwa rebooty później miałem przearanżowaną pamięć masową zgodnie z opcją 2*.

Zrobione

lsblk zeznaje:

└─sda3                                            93.8G   part
  ├─bcache0                                        5.5T   disk
  │ └─luks-142b6130-853c-4dab-ab7b-a102e7d71388    5.5T   crypt /
  └─bcache1                                        5.5T   disk
    └─luks-4e5418e6-fa2c-47b3-a4be-1b045d593a5a    5.5T   crypt

A wykres wykorzystania pamięci podręcznej wygląda dosyć optymistycznie:

http://dżogstaff.pipebreaker.pl/2016.05.24-bcache_hit.png

I jakiś taki porządek jest.

Comments


Comments powered by Disqus