Zmiany, zmiany

majek.sh Opublikowano w przez

majek.mamy.to -> majek.sh

Przenoszę się z wyspy Tonga na Świętą Helenę 🙂

A tak naprawdę, to zdałem sobie sprawę, że moja domena „mamy.to” jest dosyć wartościowa, więc zaczynam przygotowywać się, żeby być może w nieokreślonej przyszłości ją sprzedać.
Stare linki będą działały tak długo jak domena „mamy.to” pozostanie w moim władaniu. Poza tym pomyślałem, że blog może mieć po prostu swoją domenę.

Dlaczego „majek.sh„? „.sh” jest fajnym rozszerzeniem, jednym z popularnych obecnie technicznych jak np. „.io„, ale lepiej pasuje do mojego profilu. W końcu zajmuję się głównie serwerami, pisaniem skryptów (zwłaszcza w bash-u!) itp.

https

Tak, „majek.sh” też już używa szyfrowania.

Zapisywanie do wewnętrznej pamięci flash w Arduino

majek.sh Opublikowano w przez

Trochę historii

W LCD88 używam pamięci programu (flash) jako pamięci modeli. Oczywiście modele powinny dać się edytować bez wgrywania za każdym razem nowego firmware 🙂

W procesorach serii AVR zapis do pamięci flash możliwy jest tylko przez program wykonywany z obszaru bootloadera, więc do mojego projektu potrzebowałem takiego, który umożliwiałby wywołanie odpowiedniej funkcji z poziomu programu użytkownika.
Na początku zaadaptowałem swój bootloader komunikujący się po X-MODEM-ie dodając punkty wejścia do funkcji zapisujących do flasha. Niestety, X-MODEM jest dosyć upierdliwym protokołem dla zwykłego śmiertelnika, więc wpadłem na pomysł, że jakiś bootloader kompatybilny z Arduino rozwiązałby ten problem.
W obecnych czasach wszystko już zostało wynalezione i zrobione, więc zostało tylko poszukać gotowego rozwiązania. Najbardziej obiecującym był Optiboot, ale nie udostępniał możliwości zapisu flasha przez aplikację.

Czas mijał, szukałem dalej, ale nadal nie mogłem znaleźć ‚gotowca’. Bardziej zaskakujące było odkrycie, że na forum Arduino zapisywanie do flasha przez aplikację postrzegane było jak coś niemożliwego do zrobienia. Każdy temat kończył się porażką i użyciem jakiejś zewnętrznej pamięci (flash, fram czy po prostu karty SD), albo radą, żeby napisać sobie samemu bootloader 🙂

Po tych wszystkich poszukiwaniach doszedłem do wniosku, że albo muszę sam napisać bootloader, albo dodać taką funkcjonalność do jakiegoś istniejącego projektu. Pierwszą obiecującą rzeczą jaką znalazłem w problemach Optiboot-a był problem #52 z patchem na końcu. Niestety, w LCD88 pamięć RAM jest niezwykle cenna, więc alokowanie całej strony w ramie na potrzeby zapisu mi nie pasowało, zwłaszcza że można to zrobić bez tego w trybie wypełnij-skasuj-zapisz.

Rok minął i wróciłem do Optiboota. Tym razem modyfikację zamierzałem zrobić samemu. Nie było łatwo, bo musiałem się nauczyć pisać w C, poznać różne dziwne zachowania avr-gcc jak i błędy róźnych wersji, zaznajomić się z pracą na Githubie, używaniem gita i pisaniem w Arduino, bo jakiś przykład też trzeba było dołączyć. Ale w końcu się idało 🙂

Zapis do flash-a

Optiboot z możliwością zapisu przez aplikację można ściągnąć z mojego forka Optiboota (branch supermaster, również z pewnymi poprawkami niedostępnymi w oryginalnym projekcie):
https://github.com/majekw/optiboot/tree/supermaster. Jest tam również przykład jak użyć tej funkcjonalności mojego Optiboota z poziomu programu w Arduino (flash_program z obszernymi komentarzami).

Bierzcie, używajcie i dzielcie się dalej nowym lepszym Optibootem 🙂

dm-cache w Slackware

majek.sh Opublikowano w przez

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ę 🙂