Pomiędzy bitami

W poprzednich wpisach było parę przemyśleń i sugestii poprawy komfortu pracy na desktopie wyposażonym w niewielką ilość pamięci RAM, bez finalnego rozwiązania choć z paroma trickami poprawiającymi pracę, więc pora na podejście trzecie do tematu, inspirowane przez kumpla z IRC, który sprzedał mi "newsa" o zram.

Od pewnego czasu (okolice kernela 2.6.37, jeśli dobrze widzę) w kernelu Linuksa obecny jest moduł zram, pozwalający na tworzenie kompresowanych urządzeń blokowych w pamięci RAM. Wykorzystać to można podobnie jak compcache, czyli do tworzenia kompresowanego obszaru pamięci, używanego przez system przed przeniesieniem danych na swap na dysku. Idea jest prosta - swap na dysku jest tragicznie wolny i obciąża I/O, procesor zwykle się trochę nudzi, zresztą nie będzie miał dużo więcej pracy, a ilość wolnej pamięci się zwiększy.

Ogólnie zram jest ideowym spadkobiercą compcache, ale wygląda mi na prostszy i ideowo, i w użyciu. No i jest obecny w kernelu. Idea działania jest prosta: tworzymy swap z wyższym priorytetem, niż swap na dysku, na urządzeniu blokowym umieszczonym w kompresowanym obszarze pamięci. Początkowo dane tradycyjnie są w RAM, w przypadku, gdy system musi korzystać z przestrzeni wymiany, umieszcza je najpierw na swapie w RAM, a dopiero później - tradycyjnie - na swapie na dysku.

Prosty skrypt realizujący powyższe:

#!/bin/bash
modprobe zram
echo $((200*1024*1024)) > /sys/block/zram0/disksize # 200 MB
mkswap /dev/zram0
swapon -p 60 /dev/zram0

Kolejno: załadowanie modułu zram (można korzystać z parametrów), określenie rozmiaru dysku dla urządzenia /dev/zram0 na 200 MB (i jest to rozmiar swap, będący jednocześnie maksymalną wielkością zużytej pamięci, nie rozmiarem przeznaczonej pamięci pamięci!), utworzenie swapu na urządzeniu  /dev/zram0, włączenie utworzonego swap z priorytetem 60.

Podobno efekty są świetne - zaczynam testy u siebie, wstępnie nie wygląda źle, na pewno niebawem podzielę się wrażeniami (jako update do tego wpisu) po dłuższym teście. Jeśli chodzi o rozmiar swap dla modułu zram, to zacząłbym od 10-20% całości RAM (u mnie 200 MB przy 1 GB RAM). Z tego co zauważyłem, skompresowane dane zajmują w praktyce ok. 40-50% oryginalnych.

Parę przydatnych poleceń diagnostycznych:

• cat /sys/block/zram0/compr_data_size - rozmiar danych po kompresji
• cat /sys/block/zram0/orig_data_size - rozmiar nieskompresowanych danych
• cat /sys/block/zram0/mem_used_total - całkowita ilość zużytej pamięci
• swapon -s - rozmiar i wykorzystanie poszczególnych swap (inna jednostka!)

Linki w temacie, które zdecydowanie warto przejrzeć, jeśli ktoś jest bardziej zainteresowany:

• http://www.webupd8.org/2011/10/increased-performance-in-linux-with.html
• http://unix.stackexchange.com/questions/17879/cleancache-vs-zram
• https://lwn.net/Articles/454795/
• http://en.gentoo-wiki.com/wiki/Zram_disks
• http://crunchbanglinux.org/forums/topic/15344/zram-a-good-idea/

Szczególnie ostatni wpis zawiera fajny, uwzględniający ilość procesorów skrypt startowy. Można rozważyć użycie po przeanalizowaniu. IMHO dla 1-2 procesorów trochę kosmiczne wartości będą, uzależnianie wielkości swap od ilości procesorów też jest średnie, ale poprawienie to nic trudnego. Za to obsługą utworzonego urządzenia blokowego zajmie się w tamtym wariancie więcej, niż jeden procesor. Z drugiej strony kto ma więcej niż dwa rdzenie i mało RAM?

Miałem obawy co do działania hibernacji (z użyciem pm-utils, z uswsusp miałem problem...) w takiej konfiguracji. Niepotrzebnie, bo wygląda, że działa OK - zapewne hibernacja jest na tyle inteligentna, że rozpoznaje, czy ma do czynienia z fizycznym urządzeniem blokowym.

Oczywiście swap to nie jedyne możliwe zastosowanie modułu zram - więcej przykładów w linku do wiki Gentoo.

O tym, że warto monitorować stan dysku, nie trzeba - mam nadzieję - nikogo przekonywać. Wystarczy tylko dodać, że wczesne wykrycie anomalii może pozwolić na proste i bezpiecznie skopiowanie wszystkich danych. Jeśli ktoś nie chce lub nie czuje się na siłach we wnikanie w dobrze opisane na wiki parametry S.M.A.R.T, to jako wariant minimum proponuję przyjąć, że jakakolwiek różna od zera wartość dla Reallocated Sectors Count jest sygnałem, że warto szybko zrobić backup danych. A już na pewno warto spisać dysk na straty, jeśli ta wartość rośnie.

Jeśli chodzi o desktopy, to - jak podpowiada ike w komentarzu - dysk można sprawdzić korzystając z gsmartcontrol (zapewne dostępne w repozytorium pakietów dla Twojej dystrybucji). Na pewno wygodniejsze i łatwiejsze rozwiązanie.

Pisałem już o odczycie S.M.A.R.T w Debianie dla dysków w kieszeniach USB. W zasadzie temat wyglądał na wyczerpany, bo nowe smartmontools obsługują dyski w kieszeniach USB, ale... nie do końca. Niedawno miałem do czynienia z dwiema kieszeniami USB dla dysków 2,5" - na jednej smartmontools nie umiało sprawdzić stanu dysku, na drugiej działało bez problemu.

Przeszedł bym nad tym do porządku dziennego, szczególnie, że żadna z kieszeni nie była moja, ale okazało się, że moja kieszeń 3,5" też nie pozwala na sprawdzenie stanu dysku tak po prostu:

smartctl -a /dev/sdb
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

/dev/sdb: Unsupported USB bridge [0x04b4:0x6830 (0x001)]
Smartctl: please specify device type with the -d option.

Zatem jak sprawdzić dysk w kieszeni USB? Okazało się, że opcji do -d w smartmontools jest nieco więcej. Ten wpis podsunął rozwiązanie problemu, jest nim dodanie parametru -d usbcypress. Czyli ostatecznie komenda to:

smartctl -a -d usbcypress /dev/sdb

Wynik lsusb dla mojej kieszeni USB:

Bus 001 Device 002: ID 04b4:6830 Cypress Semiconductor Corp. CY7C68300A EZ-USB AT2 USB 2.0 to ATA/ATAPI

Podobno dość popularny producent chipsetów. Dla wyczerpania tematu - chyba wszystkie sprzętowe kontrolery RAID (przynajmniej znane mi) również pozwalają na sprawdzanie S.M.A.R.T dla dysków SATA. Też warto sprawdzać, bo można dostrzec nadchodzący błąd wcześniej, niż zgłosi go kontroler...

Ponieważ system po nieudanej aktualizacji już działa (w ogóle okazało się, że przyczyną "problemów z grubem" była w rzeczywistości najprawdopodobniej niedociśnięta taśma od stacji dysków) i mogę dostać się do swoich danych, to pora na konkrety i przestrogę.

Komunikat, który mówił o problemach z przejściem na dependency based boot przy upgrade z Lenny'ego do Sarge Squeeze i który może nie tyle zignorowałem, co chciałem zająć się nim po reboocie (bo zapisałem) wyglądał dokładnie tak:

Unable to migrate to dependency-based boot system

Tests have determined that problems in the boot system exist which prevent migration to
dependency-based boot sequencing:

insserv: warning: script 'K20atieventsd' missing LSB tags and overrides, insserv: warning: script
'atieventsd' missing LSB tags and overrides,

If the reported problem is a local modification, it needs to be fixed manually. If it's a bug in the
package, it should be reported to the BTS and fixed in the package. See
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot for more information about how to fix the
problems preventing migration.

To reattempt the migration process after the problems have been fixed, run "dpkg-reconfigure sysv-rc".

Skrypt atieventsd pochodzi z flgrx, z którego nie korzystałem od migracji na Lenny'ego. Taka zemsta ATI/AMD zza grobu.

Ale co sobie powalczyłem, to powalczyłem (kolejne sprawności zdobyte: instalator nie jest taki świetny i ma głupie defaulty dla instalacji gruba - kto to widział, że przy instalacji wszystkiego na sdb i niczego na sda chce umieścić gruba na sda?; rescue mode daje radę). Okazało się, że CD-ROM też już nie działa - zasilacz od dawna był słaby i miał problemy z kręceniem dwoma dyskami, ale teraz doszło do tego, że i jednym nie kręci, jeśli CD-ROM jest podpięty. No chyba, że stacja dyskietek tak bruździła. Nie wiem, nie wnikam, działa - nie dotykam (ładne rymowane motto, swoją drogą).

UPDATE: Inna możliwa przyczyna, to własny - a nie dystrybucyjny - kernel. Dziś kolejna osoba miała problem ze swoim kernelem na Squeeze, identyczne objawy (pusty /dev), a na dystrybucyjnym działało OK. Instalacja linux-image-2.6-amd64 (lub linux-image-2.6-486 dla systemów 32-bitowych) przed rozpoczęciem upgrade'u do Squeeze wydaje się dobrym pomysłem. ;-) Zresztą jest to opisane w release notes procesu aktualizacji Lenny do Squeeze (wersja robocza; TBH nie czytałem przed aktualizacją - nie wiem czy był już dostępny - mea culpa).

Minęły prawie 2 lata odkąd zrobiłem upgrade tej maszynki do Lenny'ego. Stwierdziłem, że Squeeze, którego używam od dłuższego czasu jest dobry, przydałoby się parę nowych pakietów no i można przetestować jak ten upgrade wychodzi. KDE 3.5 też jakoś nie jest tym, co mi ostatnio pasuje (a pasuje mi LXDE), więc stwierdziłem, że parę dni wolnego to dobry moment, żeby zrobić upgrade.

Problem numer jeden, który uniemożliwił mi zalecaną wersję upgrade'u, to za mała ilość wolnego miejsca. 1 GB wolnego na /, po porządkach 1,3 GB. Zdecydowanie nie to, co tygrysy lubią najbardziej. Postanowiłem, że po prostu podmienię wpisy w sources.list z lenny na squeeze, zrobię wajig update; wajig upgrade a następnie wajig dist-upgrade. Wcześniej wywaliłem jeszcze javę i OpenOffice. Gołe dist-upgrade niestety nie mieściło się.

Update poszedł bez problemu, po nim kontrolny reboot. Wszystko ładnie działa. Pora zatem na dist-upgrade. Ten też w zasadzie przebiegł bezproblemowo. Jedyne co pojawiło się z dziwnych rzeczy, to ostrzeżenie, że nie może korzystać z dependency based boot, które skrypty przeszkadzają i gdzie szukać pomocy. Oczywiście zapisałem sobie te komunikaty, dałem OK. Update się zakończył, pora na reboot.

I tu zaczęły się schody. Przy próbie montowania /home z osobnej partycji, stwierdził, że /dev/hda3 nie istnieje i zaproponował uruchamianie w maintaince mode. Hm! Stwierdziłem, że pewnie kwestia kernela (mam własny), więc doinstaluję dystrybucyjny. Prawie się udało, niestety grub nie chciał się zaktualizować - brak dysków w /dev. Faktycznie ich nie było. Trochę powalczyłem ze skryptami startowymi, które były prawdziwą przyczyną zamieszania (bez większych sukcesów, namierzyłem jedynie nieuruchomiony hald) i stwierdziłem, że skoro / jest na osobnej partycji, to najszybciej będzie zainstalować system debootstrapem. Przy okazji zmigruję z ext3 na ext4.

Tylko jak uruchomić debootstrap, jeśli USB jest nieczynne (dziękujemy padniętym kondensatorom na płycie), a live nie ma? Przełożę dysk! Tak też zrobiłem. Niedługo później system był zainstalowany. Teoretycznie, bo aktualnie przy wejściu do gruba wykonuje malowniczy reboot.

Właśnie ściągam płytę instalacyjną. Mam nadzieję, że nagrywarka i czytnik są sprawne i że po zainstalowaniu instalatorem będzie się bootował.

Podsumowując: mam dość upgrade'ów, a konkretnie żonglowania sprzętem, na dłuższy czas, a już na pewno nie na sprzęcie, gdzie w prosty sposób nie można odpalić live. Najlepiej z USB.

Sytuacja z życia wzięta: jest sobie laptop, który nie bootuje się z USB, ma dysk IDE podzielony na partycje. Po brutalnym wyłączeniu prądu (edukacja techniczna współdomowników poszła w las, niestety - wykazali się nadgorliwością przy wyłączaniu) okazuje się, że / z ReiserFS montuje się w trybie read only. Druga partycja z ext4 jest zdrowa, ale jest czymś w stylu /opt. Skoro nie można uruchomić żadnego systemu live (tzn. z USB, płyty CD nie mam pod ręką), to pozostaje maintaince mode.

Niby żaden problem - istnieją narzędzia do naprawy filesystemów, ale fsck.reiserfs nie należy do najbezpieczniejszych narzędzi, o czym zresztą sam ostrzega (i nie jest to ostrzeżenie nieuzasadnione, kiedyś nadgodziny przez to zaliczałem...). Uruchomienie z opcją --fix-fixable (co za nazwa), pomogło, ale nie do końca - dalej jest read only, a program sugeruje uruchomienie z opcją przebudowania drzewa. Tym razem ostrzeżenie zajmuje cały ekran i wprost sugeruje zrobienie backupu, najlepiej przerzucenie obrazu w bezpieczne miejsce przy pomocy ddrescue. I podają nawet adres, gdzie można uzyskać support, za jedyne 25 dolarów. Cóż, skoro tak, to jednak postaram się uruchomić jakieś liveCD, żeby zrobić porządek (cóż, wypalona płyta może się przydać kiedyś, więc bez dramatu, bo chociaż do niedawna sądziłem, że wszystko już potrafi uruchomić się z USB, to nie do końca tak jest)...

Niestety, okazuje się, że CD-ROM nie jest w pełni sprawny. Albo, że liveCD Squeeze'ego nie działa (bo płytę widzi, początek bootowania zachodzi). Na dodatek na zdrowej partycji jest ok. 7 GB miejsca, a na zepsutej zajęte ponad 8 GB, a sama ma rozmiar kilkudziesięciu GB, więc skopiowanie tam obrazu średnio wchodzi w grę, nawet z kompresją. Na inny system obrazu nie przerzucę, bo jak / jest w read only, to wifi nie działa (kabla nie sprawdzałem, nie chciało mi się podłączać). Może by działało, jakby było wicd-curses zainstalowane, ale nie było, a Xy oczywiście nie wstawały.

Ostatecznie postanawiam podmontować zdrowy filesystem, skopiować na niego tylko najpotrzebniejsze dane (czytaj: katalog domowy) i w najgorszym wypadku, jeśli nie zdoła naprawić, skończy się przekładaniem dysku i reinstalacją systemu.

Pojawia się kolejny problem - skoro / jest w trybie read only, to nie można utworzyć katalogu, by podmontować gdzieś zdrowy filesystem. I to jest ten moment, który mnie na chwilę zawiesił. Rozwiązanie okazało się trywialne - / może być w read only, ale /dev/shm to nie dotyczy. Szybkie mkdir /dev/shm/backup, zamontowanie zdrowej partycji w tym miejscu i już można na spokojnie skopiować wybrane dane.

Kilka minut później uruchomiłem fsck.reiserfs z opcją przebudowania drzewa. Tym razem dał radę. Ale poważnie myślę nad zrobieniem dodatkowej partycji ratunkowej o rozmiarze 1GB, z minimalnym systemem (znaczy łączność, narzędzia do naprawy filesystemów, ddrescue itp.).

Dzień, w którym wstajesz sobie spokojnie rano, zaparzasz kawkę i siadasz do kompa podziwiając piękne słoneczko nie musi wcale być taki fajny. Rzut oka na telefon, a tam jakieś nieodebrane. O siódmej rano. Z dyżurnego telefonu adminów! W liczbie 7!!!

No dobrze. Oddzwońmy. Okazuje się, że wywaliło serwer, na którym są wirtualki. Bywa. W zasadzie - kiedyś musiało się wydarzyć. Praktycznie wszystko jest dublowane, więc tak naprawdę nie działają tylko 2 usługi - jedna niekrytyczna a nawet nieistotna i jedna wewnętrzna (i nie do końca w naszej gestii).

A potem okazuje się, że to dzień, w którym to, co miało ratować - niszczy, B udaje, że nie stało się nic, są tacy, którym jest lepiej i tacy, którym jest gorzej, A załatwia niemożliwe (i w dobrej cenie!), zakupy można zrobić szybko w miejscach mało oczywistych, wydzielone dla poszczególnych usług klasy adresowe, które można wyroutować szybko gdzie indziej to Dobra Rzecz i wcale nie chodzi o jedną maszynę.

Na koniec dnia okazuje się, że to wszystko jednak potrwa, bo RAID to nie cudowne rozwiązanie wszystkich problemów z dyskami i czasem więcej z nim problemów, niż można by przypuszczać, a wszystko przedłuża się na piątek.

Myśl dnia: nic tak nie przygotowuje do usuwania awarii jak usuwanie awarii.

Dyski potrafią się sypnąć - pewnie każdemu zdarzyło się odzyskiwać dane z dysku, który "umarł". Dyski mechaniczne posiadają jednak bardzo przyjemną cechę, która może zapobiec utracie danych, czyli tytułowy S.M.A.R.T.. Tylko, że... nie działa w przypadku dysków podłączonych po USB. Przynajmniej w Debianie Lenny. Przynajmniej domyślnie.

Ostatnimi czasy parę osób nabyło HP Compaq T5520, czyli cienkiego klienta od HP. Sprzęt używany, niedrogi, bezszelestny. W moim przypadku wykorzystany został jako domowy routerek (plus parę usług - taki router na sterydach).

Nie tak różowo, a w zasadzie całkiem źle. Postanowiłem dodać mojej miłej możliwość korzystania z dysków w kieszeniach. Podczas instalacji nie były podłączone, więc o nich zapomniałem. Sprawa wydawała się prosta - zwykłe montowanie po UUID, dopisać do fstab i tyle. Znaczy 3 minuty roboty.

Niestety nie ma tak dobrze. Jeden z dysków okazał się być sformatowany z NTFS (próba automontowania przez HAL zakończona fiaskiem). Oczywiście pamiętam, że jest świetny NTFS-3G, który pozwala na zapis, więc nic nie wróżyło problemów - ot, następne 3 minuty roboty. Tymczasem ten driver nie pozwala na montowanie zasobów przez zwykłego usera. Szybki gógiel (liczmy 3 minuty) i... oczywiście problem jest opisany w dokumentacji i jest na to rozwiązanie, a raczej obejście.

Szybkie (3 min) wdrożenie i już mogę z poziomu użytkownika montować i odmontowywać dysk. Z CLI. Prawie jak sukces, bo przecież nie każę kobiecie na "prostym i łatwym" systemie babrać się z wierszem poleceń. No i ogólnie przydał by się jakiś wskaźnik, czy aktualnie jest zamontowane, czy też nie. No i jest coś takiego w KDE, z tego co pamiętam...

Szybkie dodanie ikonek typu dysk twardy na pulpit. Kliknięcie montuje. Ikonka się nie zmienia, niezależnie od tego, czy jest zamontowane, czy nie, opcja "odmontuj" się nie pojawia. W systemowych "urządzeniach przechowywania danych" z kolei są wymienne nośniki, ale coś HAL nie daje rady ich zamontować. Może kwestia tego, że próbuje do /media (i nie pozwala tego zmienić), a we fstab mam wpisy dla /mnt?

Na tym się skończyło wczoraj - właścicielka też chciała skorzystać z laptopa... Konkluzja: w zasadzie działa, ale nie w zadowalający sposób. Jeśli macie gotowe przepisy na eleganckie, graficzne montowanie (i odmontowanie) dysku wymiennego z NTFS pod KDE przez użytkownika bez praw roota, z możliwością zapisu (tu: Debian Lenny, ale pewnie niespecjalnie jest różnica), to chętnie je poznam. Chodzi mi o pomysły samodzielnie sprawdzone, googlać umiem i mam parę pomysłów, łączenie z wyczyszczeniem wpisów we fstab, użyciem ntfsmount. itp.

W miarę posuwania się naprzód, wpis będzie aktualizowany (ew. zamieszczę info o nowym wpisie, jeśli szczególnie długie miałoby być). Bo tylko bitwa przegrana, nie wojna. ;-)

UPDATE: Sprawa okazała się prostsza, niż myślałem. Po prostu - jak się spodziewałem - przekombinowałem. Wystarczyło dodać usera do grupy plugdev i usunąć wszystkie wpisy z fstab. Wówczas HAL pięknie sobie radzi z montowaniem i odmontowywaniem (z użyciem ntfs-3g), a user ma prawa RW. Identyfikacja następuje nie po UUID, a po LABEL. Czyli brakowało "tylko" obecności usera w grupie plugdev (mój ewidentny błąd) i zainstalowanego ntfs-3g. No ewentualnie jeszcze suid, jak opisano w FAQ.