Tag: dysk

Opublikowane w

Raspberry Pi, Raspbian i problemy z kartami microSD

Jakieś siedem tygodni temu pisałem, że padła mi karta microSD (Kingston) w Raspberry Pi. Wymieniłem na nową (Goodram). Zamontowana oszczędnie, tj. bez journala i z symlinkiem /var/lib/transmission-daemon/info kierującym na dysk twardy. Wczoraj robię aktualizację systemu, a tu nagle:

Preparing to replace libssl1.0.0:armhf 1.0.1e-2+rvt+deb7u7 (using .../libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb) ...
Unpacking replacement libssl1.0.0:armhf ... dpkg: error processing /var/cache/apt/archives/libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb (--unpack):
error creating directory `./usr/share/doc/libssl1.0.0': Input/output error
Segmentation fault Segmentation fault -bash: mbrtowc.c:92: __mbrtowc: Assertion `status == __GCONV_OK || status == __GCONV_EMPTY_INPUT || status == __GCONV_ILLEGAL_INPUT || status == __GCONV_INCOMPLETE_INPUT || status == __GCONV_FULL_OUTPUT' failed.

Piękne, prawda? Oczywiście kluczowy jest input/output error. Fsck, są błędy, naprawiony filesystem. Coś mnie tknęło i sprawdziłem badblocks (badblocks -sv). Tak jest, błędy w okolicy 90% karty (dead link). Sztuk prawie 30. Wygląda, że karta Goodram wytrzymała w komfortowych warunkach raptem 7 tygodni. Masakra.

Z tego wszystkiego zacząłem sprawdzać, co pisze na dysk (iotop -ao). Wyniki (sortowane po ilości zapisów, czas działania kilka godzin) są ciekawe:

3192 be/4 root 8.00 K 4.03 M 0.00 % 0.00 % rsyslogd -c5
2184 be/4 root 240.00 K 880.00 K 0.00 % 0.00 % nmbd -D
3341 be/4 ntp 248.00 K 188.00 K 0.00 % 0.00 % ntpd -p /var/run/ntpd.pid -g -u 102:104
5256 be/4 root 0.00 B 160.00 K 0.00 % 0.00 % [kworker/u2:2]
2911 be/4 root 208.00 K 88.00 K 0.00 % 0.00 % -bash

Jak widać, głównie rsyslog. I raczej nie ma tego wiele.

I tu zaczyna się część najciekawsza. Pamiętacie uszkodzoną kartę Kingstona? Przygotowałem się do pozbycia się jej, poleciał shred. Stwierdziłem, że uruchomię badblocks na niej. I… niespodzianka. Teraz nie zgłasza błędów. Ani w teście odczytu (domyślny), ani w niedestrukcyjnym teście zapisu (badblocks -nvs). Naprawiło się?

Zaczynam podejrzewać jakiegoś buga z przejściówką microSD -> SD (ale są dwie różne, bo każda karta miała swoją), gniazdem w rpi (ale działało OK, poza tym i badblocks, i fsck robię w laptopie). Zagadka.

Ostatecznie zmniejszyłem rozmiar partycji ext4 na karcie Kingstona i działa do tej pory bez problemu. Czyli jakieś 3 tygodnie bezproblemowego działania, bo wpis zacząłem tworzyć 12 czerwca.

UPDATE: Zwariowałem. Goodram, który ewidentnie miał błędy, bo nie tylko badblocks je wykazywał, ale nawet shred puszczony przed wyrzuceniem powodował błędy IO i nie mógł dobrnąć do końca (a próbowałem nie raz), teraz działa. Nagrałem Raspbiana dla Banana Pi, test badblockiem i… czysto. WTF?

Opublikowane w

Software RAID i wypadnięcie dysku – HOWTO

Coś złego zaczęło dziać się z jednym z dysków w jednym z desktopów. Wygląda, jakby startował, a następnie robił restart. Głośne cyknięcie, rozkręcanie się dysku, a w tym czasie system stoi. Albo umiera zasilacz, albo dysk. Albo coś gdzieś nie styka.

Ponieważ w moje ręce wpadł inny dysk, postanowiłem podłączyć go do sprawnego komputera, zdiagnozować, wyzerować i zamienić z dyskiem w padającym desktopie.

Wszystko byłoby fajnie, ale w komputerze, w którym chciałem dokonać diagnostyki jest już software RAID. Po podłączeniu dysku do diagnostyki (IDE) system wstał, ale… tylko z jednym dyskiem (zdegradowany RAID). Podłączanego dysku też nie widział. Efekt był taki, że po odpięciu dysku do diagnostyki i uruchomieniu systemu, przywitał mnie rozjechany RAID (md0):

cat /proc/mdstat 
Personalities : [raid1] 
md127 : active (auto-read-only) raid1 sda1[0]
      57584256 blocks super 1.2 [2/1] [U_]
      
md0 : active raid1 sdb2[1]
      57584256 blocks super 1.2 [2/1] [_U]

Natomiast w dmesg widoczny był wpis:

md: kicking non-fresh sda1 from array!

Wszystko jak najbardziej OK, tylko jak teraz poskładać to do kupy? TBH liczyłem, że system sam wykryje, że dysk będący częścią RAID wrócił i że ma stare dane. Czyli zrobi synchronizację. No niestety, nic nie dzieje się automagicznie. Chwila z wyszukiwarką i znalazłem rozwiązanie:

mdadm --stop /dev/md127
mdadm --add /dev/md0 /dev/sda1

Po takich komendach RAID rozpoczął synchronizację, której postęp można sprawdzić przez cat /proc/mdstat.

Tyle w kwestii podłączania dziwnych dysków do desktopa z software RAID. Przyczyną dziwnego zachowania okazało się… moje czytanie instrukcji. Nie zapakowałem dysku jak przyszedł (zlimitowany do 32GB), tylko zmieniłem zworką tryb na auto select. Znaczy tak mi się wydawało, gdyż wszystko wskazuje na to, że opis należy czytać odwrotnie. Jakichkolwiek oznaczeń gdzie dół a gdzie góra oczywiście brak.

Opublikowane w

Upał

Przejście z jesieni w lato było dość gwałtowne w tym roku. Co prawda wiosna, i to ciepła przyszła już dawno, ale niedawno zrobiło się zimno, pochmurno i w ogóle nieciekawie. Ale od paru dni w Poznaniu zrobiło się lato pełną gębą, z temperaturami rzędu 30 C. Sporo i mocno odczuwalne, z uwagi na gwałtowność zmiany.

Zmiany temperatury o dziwo dotknęły też mojego NAS opartego o Raspberry Pi. Piszę o dziwo, bo w sumie stoi blisko grzejnika i myślałem, że głównie zimą będzie tam gorąco. O ile 40 C na dysku (samo rpi mnie mało interesuje, dopóki się nie wiesza itp.) zostało przekroczone już dawno, to do tej pory utrzymywało się 41-42 C. No chyba, że pojemnik został czymś przykryty, co się zdarzyło raz czy dwa, ale można uznać za nieistotne odstępstwo od normy. Natomiast odkąd zaczęły się upały, dysk zgłaszał cały czas temperatury 44-45 C. Nawet i 46 się zdarzyło, a tak przecież nie mogło zostać. Tym bardziej, że bliźniak leżący luzem (OK, inna lokalizacja) ma w tej chwili 35 C, a 46 to jego życiowy rekord.

Postanowiłem machnąć ręką na uptime (nie, nie zbieram i generalnie nie zwracam uwagi, ale nie lubię wyłączać sprzętu) i dorobić otwory. Z poprzednich sześciu otworów wylotowych u góry obudowy (po 3 sztuki na dwóch ściankach) zrobiło się… 20 (po 5 na każdej ściance). Dodatkowo dorobiłem po 3 sztuki otworów wlotowych w dolnej części ścianek. Mam wrażenie, że filcowe nóżki są jednak trochę za niskie. Zobaczę, czy to coś pomoże… Jeśli nie, to będzie trzeba pomyśleć o jakimś separatorze pomiędzy rpi a kieszenią z dyskiem i może o podwyższeniu nóżek. W sumie w odwrotnej kolejności, bo wpływ podwyższenia nóżek łatwo przetestować prowizorycznie podkładając choćby dwa ołówki. 😉

Przy okazji, skoro już było wyłączenie z prądu, skorzystałem z watomierza i sprawdziłem, ile prądu bierze Raspberry Pi. No, w zasadzie cały zestaw, bo samego rpi nie mierzyłem. Więc hub USB + rpi + dysk 2,5″ biorą u mnie przy normalnym działaniu 5,2W. Przy obciążeniu CPU (prosty Perl) wzrasta to do 5,9W. Najbardziej obciążające jest kopiowanie na dysku USB z partycją NTFS – typowo 7,3W, maksymalnie 8W.