Tag: dysk

Opublikowane w

gocryptfs

Dawno, dawno temu przestałem używać EncFS. Przestałem z kilku powodów. Po pierwsze, pojawiło się ostrzeżenie o tym, że nie jest to rozwiązanie do końca bezpieczne. Niby nic i w moich zastosowaniach nie przeszkadzało[1], ale jakaś tam zadra w pamięci i niechęć zostały. Po drugie, zwykłe dyski zacząłem szyfrować „normalnie” przy pomocy LUKS. A backupy itp. przy pomocy GPG. Dziś odkryłem godnego następcę: gocryptfs.

Mimo zmian w używanym szyfrowaniu, po EncFS została jedna dziura: dyski zdalne typu Dropbox czy Google drive. Miło by było móc z nich korzystać „normalnie”, ale tak, żeby dane na tych dyskach były zaszyfrowane. LUKS tu nie pomoże, bo działa dla dysków lokalnych. Szyfrowanie przez GPG dla pojedynczych plików jest niewygodne, a pakowanie w jakieś archiwa jest dobre do backupów, nie do normalnego korzystania. EncFS jako overlay dostępny poprzez FUSE ze swoim szyfrowaniem per katalog był idealny. Nie trzeba z góry określać rozmiaru szyfrowanych danych, dostęp online do pojedynczych plików, z zachowaniem ich struktury.

Okazuje się, że jest godny następca dla EncFS i nazywa się gocryptfs. Nie wiem czemu nie znalazłem go wcześniej. Może odrzuciłem, bo był świeży i w golang? Może przeważył brak realnej potrzeby?

W każdym razie: jest i wygląda bardzo dobrze. Przeczytałem opis projektu i zasadę działania. Posiada sensowne założenia, był audytowany, brak przypadłości EncFS. Do tego jest bardzo szybki. Instalacja w Debianie z pakietu – żadnych kompilacji. Do tego świetna dokumentacja, proste użycie i… dopracowanie. Oczywiście open source. Działa na Linuksie, macOS, istnieją nieoficjalne porty dla Windows i Androida.

Żeby przybliżyć o czym mowa. Weźmy takie utworzenie szyfrowanego katalogu. Jedno proste polecenie, podajemy hasło, powtarzamy je i… dostajemy master key, wraz z przeznaczeniem i jak się z nim obchodzić. Aż pokażę[2], bo na stronie tego nie ma:

$ gocryptfs -init cipher/
Choose a password for protecting your files.
Password:
Repeat:

Your master key is:

d28966ae-f39ff48a-695993f9-a5e354eb-
3d31e7a1-29c834c5-31b2cb3b-b38b6cec

If the gocryptfs.conf file becomes corrupted or you ever forget your password, there is only one hope for recovery: The master key. Print it to a piece of paper and store it in a drawer. This message is only printed once.
The gocryptfs filesystem has been created successfully.
You can now mount it using: gocryptfs cipher MOUNTPOINT

Prawda, że piękne? Bardzo możliwe, że przyda się i wkrótce wrócę do tematu zdalnych dysków.

[1] Moje zastosowania: nie będą mi dyski sieciowe w stylu Dropbox grzebać po plikach, nawet jeśli nic tajnego tam nie ma.
[2] Jakby ktoś zaczynał panikować, że „ojej, master key podał” to spieszę donieść, że to z testowego katalogu utworzonego na potrzeby tego wpisu, żadnych danych tam nie ma i nie będzie.

Opublikowane w

Odmładzanie szrotu komputerowego

Jest taki komputer, z którego korzystam w domu rodziców. Poleasingowy desktop, z monitorem CRT 17″, czyli zabytek. Służy do przeglądania WWW, jako terminal oraz jako dodatkowy storage na backupy zdjęć na starych, niewielkich dyskach 3,5″. Korzystam z niego sumarycznie tydzień, może dwa w roku. Kiedyś niewiele więcej. Wyposażony w Intel(R) Core(TM)2 Duo CPU E4600 @ 2.40GHz i 2 GB RAM, w zasadzie spełniał swoje zadanie.

Niestety, 2 GB RAM powodowały, że z niektórymi rzeczami nie dawał rady. I pół biedy, jeśli było to kilka zakładek WWW. Gorzej, że zaczął mieć problem z otwarciem co większych zdjęć z poczty. Korzystam z niego na tyle rzadko, że wymiana sprzętu nie miała sensu. Z drugiej strony wyprzedaję trochę starych podzespołów, więc wiem, jak niskie są ceny. Postanowiłem sprawdzić, czy da się dołożyć pamięci RAM.

Płyta główna

Okazało się, że płyta to DQ35JO i obsługuje wg dmidecode maksymalnie do 8 GB RAM DDR2. Co więcej, ma cztery sloty. Rozważałem dokupienie 2×2 GB, co pozwoliłoby rozbudować pamięć do 4 GB, a przy odrobinie szczęścia do 6 GB. Ceny do zakupu od ręki były nieadekwatne (ok. 40 zł za ww. konfigurację), ale temat nie był pilny. Trochę policytowałem i kupiłem 2×1 GB RAM za… 1 zł. Plus wysyłka.

Procesor

Trochę się rozochociłem, więc sprawdziłem, jakie jeszcze procesory obsługuje płyta. Znowu pozytywne zaskoczenie, bo można włożyć całkiem sporo modeli procesorów, w tym Core 2 Quad. Ceny tych ostatnich znowu były nieadekwatne, ale znalazłem dostępne od ręki Intel Core 2 Duo E8400 3.0 GHz za… 5 zł. Specyfikacja tutaj. Jak widać TDP bez zmian, taktowanie 25% większe, cache L2 trzy razy (sic!) większy. Grzech nie wymienić, znaczy, bo procesor szybszy. Oczywiście to sztuka dla sztuki, pewnie nie odczuję w praktyce różnicy, ale chodzi głównie of fun z grzebania w sprzęcie.

Zakupy

Szczęśliwie sprzedawca miał w ofercie pastę termoprzewodzącą na procesor. Zrobiło się całe 11 zł plus wysyłka, która niemal podwajała cenę. Jak szaleć to szaleć, z miejscem na dyskach też było słabo, więc dorzuciłem dysk 500 GB za 35 zł dzięki czemu wysyłka załapała się na Smart! Dysk się przyda, bo w maszynie był stary, mały dysk IDE oraz niewiele większy SATA. Istotniejsze dane tzn. backupy leżą sobie na softraid RAID1, pozostała część to system i śmieci. Jedyne o czym zapomniałem i musiałem dokupić później, już gdzie indziej, to przejściówka do zasilania dysku SATA za 7 zł z wysyłką.

Wymiana odbyła się błyskawicznie. Najpierw wymieniony RAM i sprawdzenie przy pomocy memtest86+, potem procesor. Cieszę się, że nie skusiłem się na mocniejszy procesor, bo radiator jest… taki sobie. Jakiś stockowy zapewne, mało metalu, nie wygląda na coś potrafiącego odprowadzać większą ilość ciepła.

Ekonomia

Oczywiście z ekonomicznego punktu widzenia sens jest żaden, bo chodziło o fun. Zamiast rozbudowywać stary sprzęt, pewnie bardziej opłaca się kupić gotowy, kompletny zestaw z 4 GB RAM i dyskiem. Sprawdziłem i używany stacjonarny komputer z Core 2 Quad można kupić już za 170 zł. A Core 2 Duo za 130 zł. I to biorąc tylko pod uwagę oferty od Super Sprzedawców.

Oczywiście kupując takiego szrota „do WWW” warto zwrócić uwagę na procesor i rozmiar dysku. Dopłacając symboliczne kwoty można kupić znacznie lepszy sprzęt. Do sporadycznego korzystania pobór prądu nie robi różnicy. Jeśli jednak komputer miałby być włączony codziennie, przez dłuższy czas, warto przeliczyć kalkulatorem, czy nie lepiej zainwestować w coś bardziej energooszczędnego.

Opublikowane w

KVM i task blocked for more than 120 seconds – solved

Sprawę miałem opisać już jakiś czas temu i zapomniałem, a jest szansa, że komuś się przyda. Był sobie serwer, na którym działało trochę VPSów. Wszystkie KVM, wszystkie z systemem plików ext4 i obrazem dysku qcow2. Czyli standard. Sprzęt nie pierwszej młodości, ale działały względnie stabilnie. Poza jedną, w sumie najbardziej obciążoną, bo działał w niej jeden z serwerów Zabbixa. Niespecjalnie obciążony w porównaniu z innymi, w których jednak żaden nie działał w KVM.

Tej jednej zdarzał się zaliczyć zwis, z komunikatami dotyczącymi KVM i task blocked for more than 120 seconds:

kernel: INFO: task XXX blocked for more than 120 seconds.kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Wymagany był reboot wirtualki. Dotyczyło to różnych tasków, a całość działa się losowo. Potrafiło działać przez kilka tygodni, a potrafiło wywalić się co parę dni, co nie ułatwiało diagnostyki. Początkowo działo się to na tyle rzadko, że sprawa została zignorowana. Jedkal w miarę wzrostu obciążenia maszyny fizycznej, problem się nasilał. Objaw był taki, że operacje wymagające zapisu na dysk nie wykonywały się (czyli monitoring zdychał). Zacząłem szukać przyczyn. Pierwotnie podejrzenie padło na coś, co wykonuje się z crona, bo sporo procesów crona wisiało. Jedak przejrzenie skryptów pokazało, że niespecjalnie mogą one być przyczyną

Wyglądało, jakby momentami coś nie wyrabiało się dostępem do dysków w momentach większego obciążenia. Z tym, że znowu – widać było, że nie jest to deterministyczne. Ponieważ maszyny jak wspomniałem starawe, to podejrzenie padło na sprzęt – problemy z dostępem do dysków potrafią robić cuda. SMART pokazywał, że wszystko OK, ale sprawdzić nie zawadzi… Przeniesienie wirtualki na inną, mniej obciążoną maszynę fizyczną nie przyniosło rezultatów – wieszało się nadal, chociaż rzadziej.

Oczywiście wyłączenie komunikatu, które jest w nim wspomniane, nie rozwiązuje problemu. W międzyczasie trafiłem na opis rozwiązania problemu KVM task blocked, czyli zmniejszenie vm.dirty_ratio oraz vm.dirty_backgroud_ratio. Tylko że… to nie pomogło. Nie pomogło także zwiększenie kernel.hung_task_timeout_secs początkowo do 180, potem do 300 sekund. Było trochę lepiej, ale problem nadal występował. Pół żartem, pół serio zacząłem się zastanawiać nad automatycznym rebootem po wystąpieniu problemu (zawsze to krótsza przerwa), ale to brzydkie obejście, nie rozwiązanie. Tym bardziej, że w miarę wzrostu obciążenia i VPSa, i maszyny fizycznej na której on działał, problem zaczął występować częściej. Góra co parę dni. Paradoksalnie, dobrze się stało, bo i motywacja większa, i sprawdzanie efektu wprowadzonych zmian łatwiejsze.

Z braku opisów w sieci, pomocy znajomych adminów i innych pomysłów zacząłem sprawdzać po kolei wszystko. Od fsck systemu plików, przez nowsze wersje kernela, zarówno na maszynie fizycznej, jak i na wirtualce – a nuż coś poprawili. Bez rezultatu. Ostatecznie postanowiłem zmienić format dysku wirtualki z qcow2 na raw i… trafiony, zatopiony – wirtualka zaczęła działać stabilnie.

Dla pewności wróciłem jeszcze z raw z powrotem na qcow2, na wypadek, gdyby chodziło o jakieś błędy, których nie wykrywało narzędzie do sprawdzania qcow2, ale… problem natychmiast wrócił. Gwoli ścisłości: ww. tuning dotyczący parametrów kernela z serii vm.dirty został zachowany.