dm-cache w Slackware

Opublikowano w 2015/03/12 przez majek2015/04/07

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)

Ściągnąć źródła pakietu LVM2 z ftp://ftp.osuosl.org/pub/slackware/slackware64-14.1/source/a/lvm2/
Ściągnąć świeższą wersję żródeł LVM2 z ftp://sources.redhat.com/pub/lvm2/releases/LVM2.2.02.116.tgz
Ś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
Ś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
Zbudować nowy pakiet z lvm2:
sh lvm2.SlackBuild
Zaktualizować pakiet lvm2 nowym, który powinien być w katalogu /tmp
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
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.

Na początek, dysk ssd na cache musi być częścią volume grupy:
vgextend vg_group /dev/sdb1
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
Łączymy wolumen cache z wolumenem do przyspieszenia:
lvconvert --type cache --cachepool vg_group/cacheX vg_group/lv_home
Cieszymy się 🙂

Lampki choinkowe na Arduino i led-ach z kontrolerem WS2811 :-)

Opublikowano w 2015/01/08 przez majek2015/02/09

Gdzieś na początku listopada odkryłem diody RGB LED z wbudowanym kontrolerem: WS2812 i inne podobne. Pomysł wydawał mi się na tyle fajny, że zapragnąłem też coś takiego mieć do zabawy 🙂
Co więcej, sterowniki stały się na tyle popularne i tanie, że są nawet montowane wewnątrz diod LED, jak na przykład WS2812 w tej diodzie:

Zważywszy porę roku, stało się oczywiste, że najlepiej byłoby sobie z tego zrobić lampki na choinkę. Chwila szukania i okazało się, że na Aliexpress sprzedają już gotowe takie diody polutowane w łańcuszki 🙂
Moje LEDy nie mają co prawda układów wewnątrz diod, a na małej płyteczce zalanej twardym silikonem, ale za to były tańsze. Zwłaszcza jak kupuje się łańcuszek z 50 sztuk 🙂

Dzień przed Wigilią nadal wszystko leżało luzem czekając na 'tą właściwą chwilę’, ale jako, że to już była ostatnia szansa na sensowne wykorzystanie tego, to trzeba się było zebrać do pracy 🙂

Połączenie tego do kupy było całkiem proste, bo to tylko 3 rzeczy: zasilacz 5V, płyteczka Arduino Pro Mini i łańcuszek LED-ów.

Oprogramowanie protokołu było większym wyzwaniem – przebiegi generowane dla WS2811 muszą być dosyć dokładnie, a najkrótsze impulsy mają tylko 8 cykli zegara w Atmega328 (taktowanej 16MHz), więc wybrałem znowu (jak zwykle) assembler 🙂
Żeby było trudniej, była już 3 rano jak zacząłem debugować 🙂 Szczerze mówiąć, to bez mojego nowego oscyloskopu znalezienie 3 błędów jakie zrobiłem potrwałoby pewnie grube godziny. Zwłaszcza, że Chińczyk, który sprzedawał te diody opisał je jako: ’we sent WS2811. Or we may sent UCS1903′ (czyli wysyłamy WS2811 lub UCS1903) – dwa różne kontrolery z różnymi protokołami i nikt nie wie który tak naprawdę dostałem.
Na szczęśćie to był WS2811, więc pierwsza (poprawna) implementacja protokołu zadziałała.

Dodałem do tego kilka prostych funkcji do poruszania światła po łańcuszku i całość wylądowała na choince.

Cały kod z tego 'jednonocnego projektu’ jest dostępny na moim Githubie: https://github.com/majekw/wsled

A tak wyglądają światełka na mojej choince:

Initrd w Slackware

Opublikowano w 2014/12/26 przez majek2015/02/20

W Slackware jest tylko małe howto o initrd, trochę więcej jest w manualu, ale reszta jest już owiana tajemnicą 🙂

Przestawiłem się pełnego kernela (w zasadzie zawsze kompilowanego przeze mnie) na minimalne z initrd ładnych kilka lat temu. Od tego czasu wiele się nauczyłem o initrd, czasem w dosyć bolesny sposób 🙂

Dlatego tym razem opiszę swoją wersję radzenia sobie z initrd (trochę inną niż w manie i oficjalnym readme).

Instalacja

W czasie instalacji Slackware potrzebne są następujące pakiety:

kernel-generic (ale nie kernel-huge!)
kernel-modules
mkinitd

i oczywiście inne pakiety jakie lubi się mieć 🙂
Należy pamiętać, żeby NIE instalować pakietu kernel-huge.

Trzeba zainstalować wszystko jak zwykle, przejść przez ustawienia Lilo, stref czasowych itd. Na koniec NIE robimy reboota, bo to jeszcze nie koniec!

Teraz nadszedł czas na przygotowanie nowego initrd.

Robimy chroot do /mnt (tam cały nowy system powinien być nadal zamontowany)
Robimy kopię domyślnej konfiguracji mkinitrd:
cp /etc/mkinitrd.conf.sample /etc/mkinitrd.conf
Edytujemy /etc/mkinitrd.conf ulubionym edytorem i ustawiamy kilka zmiennych/opcji:
- odkomentowujemy i ustawiamy MODULE_LIST i ROOTFS na typ filesystemu użytego jako nasz root, na przykład:
  ROOTFS="ext3"
  MODULE_LIST="ext3"
  
  Nie należy martwić się o moduły zależne, bo te zostaną dodane automatycznie.
- jeżeli używamy softwarowego raida, to odkomentowujemy i ustawiamy
  RAID="1"
- jeżeli używamy LVM-a lub szyfrowania, to trzeba odkomentować
  LVM="1"
- zalecam również nadać dla SOURCE_TREE i OUTPUT_IMAGE jakieś unikalne nazwy, np.
  SOURCE_TREE="/boot/initrd-tree-3.10.12"
  OUTPUT_IMAGE="/boot/initrd-3.10.12.gz"
  
  Nie trzeba tego robić jeżeli nigdy nie będziesz się bawił z innymi kernelami niż ten z dystrybucji.
Wygenerować nowe initrd przez: mkinitrd -F
Dodać nowe initrd do lilo.conf tuż po linijce z nazwą kernela (zaczynającą się od image=), czyli żeby wyglądało to jakoś tak:
image = /boot/vmlinuz-generic-3.10.12
initrd = /boot/initrd-3.10.12.gz
Wyjść z chroot-a i zainstalować jeszcze raz lilo z nowym konfigiem:
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
lilo -r /mnt

Teraz już można przeładować system i cieszyć się ze Slackware z initrd:-)

Jaka jest zaleta tego sposobu w porównaniu do ręcznego odpalenia mkinitrd z mnóstwem dziwnych opcji? Myślę, że będzie to widać w dalszej części.

Utrzymanie systemu

Czasami przychodzi taki moment, gdy zmienimy kernel, coś uaktualnimy i trzeba w końcu przebudować initrd.

Są 2 podejścia do utrzymywania Slackware z initrd:

Jedno initrd dla wszystkich kerneli
Każdy kernel lub nawet pozycja w lilo ma swoje initrd

Jedno initrd dla wszystkich

Na początek należy się upewnić, że mamy zakomentowane CLEAR_TREE lub ustawione na 0 w mkinitrd.conf!

Po instalacji nowego kernela, ale działając jeszcze na starym, trzeba ustawić KERNEL_VERSION na wersje nowego kernela, np.

KERNEL_VERSION="3.17.4"

Po tym wystarczy uruchomić mkinitrd -F
To wszystko, teraz initrd ma moduły tak dla starego kernela jak i dla nowego.
Oczywiście trzeba dodać nową pozycję w lilo.conf dla nowego kernela z dokładnie tą samą nazwą initrd jak dla starego.
Jeżeli robimy tylko upgrade kernela, to w takim wypadku nie trzeba nawet dotykać lilo.conf (tak długo jak linijka image= odwołuje się do linku vmlinuz wskazującego na aktualny kernel).
W obu przypadkach na końcu trzeba oczywiście uruchomić lilo.

Od czasu do czasu warto posprzątać stare i nieużywane moduły z initrd. Robi się to przez usunięcie jednego katalogu z /boot/initrd-tree/lib/modules/old-kernel-version i wygenerowanie nowego initrd jak zwykle przez mkinitrd -F. I uruchomienie lilo na koniec 🙂

Mam nadzieję, że teraz już widać przewagę użycia mkinitrd.conf zamiast pamiętania wszystkich dziwnych przełączników jakie ostatnio użyliśmy do wygenerowania poprzedniego initrd (czasem ładnych kilka miesięcy temu).

Osobne initrd dla każdego kernela

To podejście nie ma większego sensu jeżeli masz tylko jeden system i używasz tylko jednego dystrybucyjnego kernela, który czasem uaktualniasz.

Poza tym osobne initrd jest nawet łatwiejsze niż podejście 'jedno dla wszystkich’.
Jedynym minusem jest to, że przełącznik -F do mkinitrd powoduje wczytanie zawsze tego samego konfiga (/etc/mkinitrd.conf) i nie ma innej opcji podania innego konfiga, więc za każdym razem trzeba sobie skopiować swój odpowiedni konfig w to miejsce.
Czyli dla pierwszego kernela powinniśmy ustawić sobie co najmniej unikalne SOURCE_TREE, OUTPUT_IMAGE i KERNEL_VERSION. Generujemy nowe initrd przez mkinitrd -F i robimy backup mkinitrd.conf do np. mkinitrd.conf.3.10.17.
Dla każdego następnego kernela zmieniamy sobie odpowiednie opcje w mkinitrd.conf, generujemy initrd, robimy backup i tak dalej.
Tym sposobem można mieć wiele różnych initrd i zapisanych konfigów do przebudowania każdego z nich. Jest to najbezpieczniejsza metoda przy zabawach z nowym kernelem czy opcjami initrd, bo zawsze mamy jeszcze starą i działającą wersję.

Osobiście używam podejścia mieszanego – dla każdej wersji systemu inne initrd (czyli Slackware 14.0 ma swoje, 14.1 ma inne). Kernele w obrębie jednej wersji zazwyczaj mam już ze wspólnym initrd. Eksperymenty też zazwyczaj mam już osobno.

To by było na tyle o tej prostszej części initrd 🙂
Następnym razem opiszę jak użyć initrd z zaszyfrowanym root-em lub nawet root-em na zaszyfrowanym lvm-ie 🙂

Uaktualnienie 2015.02.20

Znalazłem całkiem niezłą dokumentację w tym temacie na Slackware Documentation Project. Wygląda na to, że niezbyt dobrze sprawdziłem co jest już dostępne w tym temacie 🙂

Złodziej zdjęć

Opublikowano w 2014/12/14 przez majek2014/12/14

Ostatnio w logach bloga znalazłem, że jedno ze zdjęć zrobiło się dosyć popularne:

Obrazek pochodzi z tego wpisu: Analizator widma na RTL2832U – część 2

Czasem ludzie wklejają moje zdjęcia czy obrazki na forach, żeby wzbogacić dyskusję. Ale tym razem okazało się, że to jeden sprzedawca z Włoch użył go na aukcji na eBay-u (właściwie nie tylko mojego zdjęcia). Co więcej, do aukcji obrazek wklejony został tak, że za każdym razem jest pobierany z mojego serwera, w pełnej rozdzielczości zjadając mi pasmo. Wszystko oczywiście bez żadnego pytania.

Jest sporo metod na radzenie sobie z takimi nadużyciami, ale tym razem postanowiłem wykrzystać to jako darmową promocję 🙂

Przygotowałem nową 'ulepszoną’ wersję obrazka (przy okazji o wiele mniejszą pod względem kB):

I dodałem nową regułkę do .htaccess, żeby wszystkie odwołania z eBay-a do tego pliku przekierowywał na nową wersję:

RewriteCond %{HTTP_REFERER} ebaydesc\.com/|ebay\.it/
RewriteRule ^wp-content/uploads/2013/06/sdrsharp\.png /wp-content/uploads/2014/12/sdrsharp-ebay.jpg [R=302,L]

Teraz jego aukcja pokazuje mój nowy 'ulepszony’ obrazek 🙂

Lutowanie kabla AWG10 do wtyczki XT60

Opublikowano w 2014/08/16 przez majek2021/04/18

Jak potrzeba dłużej latać, to pojemniejsza bateria może być w tym pomocna (do pewnego progu) 🙂
Ale większość baterii przystosowanych do większych prądów ma również kable i złączki dostosowane do tego zastosowania.
Czasami jest to problem. W Tricopterze używam zwykłych wtyczek XT60, bo ich obciążalność jest w sam raz do tego zastosowania. Jak używałem baterii o pojemności 1800-2200mAh, to wszystko było ok, bo też miały takie końcówki.

Jak kupiłem akumulator 4000mAh z końcówką HXT4mm, to od razu kupiłem sobie przejściówkę z HXT na XT60. Problem rozwiązany.

Niedługo i 4000mAh przestało wystarczać 🙂
Dlatego kupiłem 5000mAh, ale ten akumulator miał jeszcze większe wtyczki: bananowe 5.5m. Tym razem postanowiłem zmienić wtyczkę na XT60 zamiast kombinować z ciężką przejściówką.
Na forum rc-fpv.pl akurat trwała dyskusja na temat problemów z lutowaniem końcówek XT60 do tak grubych kabli jak AWG10, które są akurat w moim nowym akumulatorze.
Sposobów na polutowanie tego jest tam kilka, i ja też mam swój 🙂

Ponieważ 'obraz wart tysiąca słów’ czy 'zobaczyć oznacza uwierzyć’, więc nagrałem filmik jak to wszytko lutuję. 🙂

Co jest potrzebne:

pocynować końcówki przewodu (moje już były pocynowane, bo odlutowałem je od starych końcówek zamiast odciąć)
obrócić piny w wtyczce XT60, żeby były 'otwarte’ w przeciwnych kierunkach, na zewnątrz wtyczki (do tego można użyć płaskich szczypcy czy kombinerek)
użyć 'trzecią rękę’ – przydaje się do trzymania tego wszystkiego i na dodatek jest odporna na ciepło
lutować po jednym przewodzie na raz – dla bezpieczeństwa – lepiej nie mieć szansy zwarcia tych przewodów
roztopić trochę cyny w samej rurce złączki
wsadzić końcówkę lutownicy w tą cynę i jednocześnie w to miejsce docisnąć lutowany przewód – im większą powierzchnią grot będzie oddawał ciepło do złącza i przewodu, tym szybciej i łatwiej będzie to polutować
nie trzymaj przewodu rękami – za bardzo się rozgrzewa, lepiej użyć szczypiec czy pęsety
trochę cierpliwości z zależności od mocy lutownicy (moja ma 65W) i doświadczenia

Powodzenia 🙂