Wyciszanie grzejnika

Pod koniec zeszłego roku komputer robiący za grzejnik przestał działać. Padł dysk. Software RAID na dwóch partycjach niewiele pomógł. Tzn. pomógł na tyle, że były sygnały, że wkrótce się skończy. Gdybym miał jakieś ważniejsze dane, to zapewne zdążyłbym zgrać. Inna sprawa, że wg statystyk zrobionych przez Google, IIRC 30% dysków nie ma żadnych, ale to naprawdę żadnych objawów w S.M.A.R.T, zanim padną. Jakby komuś bardzo zależało i nie mógł znaleźć – dajcie znać w komentarzach, to poszukam tych statystyk Dzięki GDR! za podesłanie linka!

Wracając do tematu. Wymieniłem komputer w domu u rodziców, przełożyłem ze starego dysk do nowego. Zapomniałem o tym, włączyłem go i… praktycznie totalna cisza. Mimo w sumie trzech wentylatorów (zasilacz, radiator na procesorze i wentylator jak od zasilacza puszczony na 5V chłodzący kartę graficzną). Okazało się, że głównym hałasującym był dysk (Seagate 60 GB).

To podsunęło mi pomysł, żeby spróbować tego samego z grzejnikiem. W końcu komputer uruchamiający się z pendrive był ćwiczony wielokrotnie. Może nie w tak hardcore’owej wersji, bo jednak zawsze na podorędziu był dysk wpięty po USB, ale to przecież drobiazg. Przy okazji nauczyłem się patentu: jeśli komputer nie ma bootowania z USB w BIOSie, albo ma takie, że nie potrafi zabootować się z pendrive’a, to można zabootować z CD-ROM i kazać bootować z USB. Wymaga co prawda sprawnego napędu CD-ROM, ale działa. 🙂

Dzisiaj przywiozłem grzejnik. System zainstalowany na pendrive, póki co bez tuningu pod kątem trwałości tego ostatniego. Znaczy jest ext2, nie ma swap, ale reszty opcji nie miałem kiedy włączyć. Oczywiście tym razem nie będzie dysku tylko do odczytu, bo mprime musi gdzieś zapisywać wyniki (BTW przechodzę wyłącznie na wstępną faktoryzację – w jeden sezon grzewczy i tak nie jestem w stanie „konkursowej” liczby przeliczyć), ale to nie powód, by katować flasha ponad potrzebę.

Pamiętałem, że wentylatory w tej maszynie dość szumią, więc przypomniał mi się zacny wpis z Majsterkowo.pl o naprawie głośnych wentylatorów. Co prawda wyciąganie zawleczki i wyciąganie ośki uważam za overkill, ale rozebrałem i wentylator od procesora, i ten w zasilaczu i przesmarowałem sprawdzonym sposobem (kropelka oleju maszynowego). Jest o niebo lepiej, choć nadal troszkę go słychać. Winny jest badziewny radiator i wentylator zamontowany na nim, który jakby ma lekkie bicie. I w ogóle trochę mały jest ten radiator, i mniejszy niż w zasilaczu ma wentylator. Trochę żałuję, że nie przełożyłem z mojego starego domowego komputera procesora (Athlon 2200+) – obecnie jest Sempron 2300+, czyli słabszy. No i oczywiście radiatora (tego z niesłyszalnym praktycznie wentylatorem). Przy okazji mogłem też wymienić wentylator w zasilaczu, choćby na ten, który dmuchał na grafikę w starym komputerze. No ale nie było czasu… ;-/

Przy okazji otwierania zasilacza w celu przesmarowania i wyczyszczenia wentylatora znalazłem spore pokłady kurzu. Niestety, okazuje się, że samo odkurzenie zasilacza przez szczeliny nie pomaga, a sprężonego powietrza nie miałem nigdy pod ręką. Dodatkowo wyszło na jaw, że jeden z kondensatorów trochę wyciekł. Mam już lutownicę, ale nie miałem kondensatora na wymianę. Póki co działa, więc nie ruszam. Mam nadzieję, że nie odparuje razem z płytą…

UPDATE: Note for myself: w tym roku dniem uruchomienia grzejnika jest 02.12.2012. I nie jest to początek sezonu grzewczego.

UPDATE2: Może i było lepiej przez chwilę, ale dość szybko się pogorszyło. Tym razem pamiętałem i wyjąłem wentylator z nieużywanego komputera. Okazuje się, że nie był na 5V, a i tak był praktycznie niesłyszalny. Jakiś Arctic, które kupiłem za grosze w większej ilości wieki temu. Co prawda z mocowaniem był cyrk, bo żeby wkręcić cztery wkręty brakuje jakichś 5 mm na długości radiatora, ale dało się zamocować na dwóch (skombinowanych z kołków, bo wentylator różni się głównie wysokością, więc oryginalne nie pasowały). 1700 RPM w tej chwili i cisza – ten z zasilacza jest głośniejszy.

Praca na desktopie z małą ilością RAM po raz trzeci – zram.

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 na swap!), 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:

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.

Sprawdzanie dysku USB w Debianie.

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…