Tag: dysk

Opublikowane w

Banana Pi – alternatywa dla Raspberry Pi

Zwykle nie piszę o hardware, nawet opartym na ARM, ale tu zrobię wyjątek. Raspberry Pi od początku średnio mi się podobało, ale nowy projekt czyli Banana Pi, zrobiony przez inną ekipę jest naprawdę ciekawy. Jak to ktoś ładnie ujął, Chińczycy wezmą i zrobią lepiej.

Zmiany w stosunku do Raspberry Pi:

  • Ethernet 10/100/1000 (przy NAS po kablu może robić kolosalną różnicę, choć wątpię, by faktycznie wyciągało pełen gigabit),
  • Wbudowane złącze SATA (znowu spora różnica dla NAS),
  • Procesor Corex A7 dual core, czyli dwa rdzenie prawdopodobnie po 1 GHz każdy, czyli niemal trzy razy tyle MHz ile ma niepodkręcane Raspberry Pi,
  • 1 GB RAM, czyli dwa razy więcej,
  • wbudowany IR (odbiornik podczerwieni), czyli teoretycznie trywialne do zrobienia sterowanie pilotem

Zachowane złącza GPIO, wymiary i niska cena. Z tego co piszą, działa dedykowany dla Raspberry Pi Raspbian. Wspierany jest także Debian (czyżby niemodyfikowany?). Co lepsze, użycie nowszego procesora oznacza, że będzie działać architektura armhf, więc nie ma potrzeby stosowania protezy w postaci Raspbiana.

Koszt to niby 43 dolary, ale za mniej niż 50 nie znalazłem do kupienia. Tak czy inaczej IMO zdecydowanie warto dopłacić. Niebawem zamówię i najprawdopodobniej wymienię silnik obecnego NAS opartego na Raspberry Pi.

I jeszcze stronka w Wikipedii poświęcona Banana Pi.

UPDATE: Dzięki namiarom z komentarzy (thx Zal!) wiemy więcej. Zapowiadało się dobrze i jest dobrze. Przynajmniej jeśli chodzi o benchmark Banana Pi vs. Raspberry Pi. Dla niecierpliwych: banan ma sieciówkę (o go głównie były obawy) 6-7 razy szybszą (iperf). Za to uwaga, Banana Pi jest nieco większe od Raspberry Pi i nie wszędzie się zmieści. Jak donosi też mniej pochlebna recenzja, nie wszystkie rozszerzenia będą pasowały z uwagi na przesunięcie niektórych złącz.

UPDATE: W jednym z kolejnych wpisów opisuję, jak zrobić z maszynki z Linuksem router, GSM/LTE z Wi-Fi. Z uwagi na niewielkie rozmiary i mały pobór energii Banana Pi świetnie się do tego nada.

Opublikowane w

Raspberry Pi jako NAS

Nie bardzo miałem co zrobić z moim Raspberry Pi, a przecież nie może się maszynka nudzić. Przy czym łącze do domu mam całkiem fajne i w praktyce po WiFi nie do wykorzystania[1], więc postanowiłem zrobić sobie seeder torrentów[2], serwer do backupu innych maszynek i ogólnie NAS dla domu. Niby coś jak Dockstar, ale nie głównie router, tylko z akcentem na NAS. W sumie może kiedyś dorzucę mini hosting dla własnych gadżetów. Na razie leży to sobie na dedyku, zresztą rpi demonem szybkości nie jest, więc z czymkolwiek ponad statyczne strony może być ciężko…

Nierozwiązaną miałem kwestię obudowy dla Raspberry Pi. Przy czym, gdybym zrobił to tradycyjnie, to byłby hub USB, kabelki do rpi, kabelki do dysku, kabel do zasilania, kabel do routera. Trochę plątanina, którą ciężko utrzymać w czystości, bo ani odkurzyć porządnie, ani przetrzeć szmatką. No i podatne na usterki, bo taki kabel na wierzchu jednak łatwo szturchnąć. Postanowiłem, że spróbuję upchać to wszystko w jedno pudło i zacząłem rozglądać się za jakimś dającym się wykorzystać gotowcem.

Pierwsze co mi wpadło w oko, to pudełka do żywności w Netto. Trzy sztuki (różnej wielkości) za 8 zł. Szybka przymiarka ujawniła, że średnie, na które liczyłem się nie nadaje, bo jest za małe. Za to największe pasuje. Na styk, zresztą, ale to dobrze – można zrezygnować z mocowania elementów w środku. Trochę bałem się, że plastik nie będzie odporny na temperaturę, ale niesłusznie. Według opisu pojemniki są przeznaczone do temperatur od -30 do +100 C i do użytku w mikrofali.

Układ elementów w pudełku następujący: na dole dysk w kieszeni, jako element najchłodniejszy i najcięższy, ma lekko miękkie etui z tworzywa, więc na nim bez obaw mogę położyć Raspberry Pi. Hub USB Unitek przymocowany do pokrywki przy pomocy opasek samozaciskowych (AKA żmijki). Po pierwsze jest metalowy, więc nie chcę go mieć w pobliżu rpi z uwagi na możliwe zwarcia, po drugie jego ażurowa obudowa sugeruje, że może się grzać. Pierwotnie rpi miało leżeć wzdłuż dysku, ale nie pasowało to do układu kabli. Zresztą jest na tyle małe, że w poprzek też praktycznie nie wystaje poza obrys dysku.

Miałem obawy o temperaturę w środku, bo wymiana powietrza jest mocno utrudniona. Nie było źle – S.M.A.R.T. dla dysku pokazywał góra 40 stopni, ale ostatecznie zdecydowałem się na dodanie otworów od spodu pudełka (w zamyśle wlot zimnego), zrobienie nóżek z podkładek filcowych (samoprzylepne do mebli) w celu umożliwienia dopływu powietrza do nich, oraz kilku otworów na samej górze z boku (w zamyśle wylot ciepłego powietrza; nie pokrywka, żeby kurz nie wpadał od góry do środka). Dzięki temu jakiś tam przepływ jest i odrobinę chłodniej.

Uroki notek po czasie są takie, że mogę napisać, jak to działało i czemu przestało. Działało bardzo dobrze i stabilnie. Jedyne restarty to braki prądu (rzadko się zdarza, ale się zdarza) lub wymiana kernela. Uptime po kilkadziesiąt dni. Wydajnościowo szału nie ma. Sam NTFS via ntfs-3g potrafił wskoczyć w top na pierwsze miejsce z kilkadziesiąt procent (40-60) zużycia CPU. Oczywiście NTFS jest tam tymczasowy – po prostu chwyciłem do testu dysk, który robił za przenośny. No i całość jak najbardziej wyrabiała się z serwowaniem plików po sambie po WiF. Tyle, że cokolwiek więcej w tym czasie na rpi było problematyczne. Dysk po USB jak najbardziej daje radę, ale ten element miałem przetestowany już wcześniej.

Dzięki temu, że miałem notkę o testowym uruchomieniu Raspberry Pi, wiem dość dokładnie, ile działało. Problemy (niemożność zalogowania się po SSH) zaczęły się na początku kwietnia, czyli podziałało jakieś 4 m-ce. Niestety, trafnie przewidziałem powód: pad karty micro SD (ja wiedziałem, że tak będzie… pamięci flash nie nadają się do zapisu ja wiedziałem, że tak będzie…). Początkowo uważałem, że to zwykłe zawieszenie, ale po restarcie po paru godzinach sytuacja się powtórzyła. Wyjąłem kartę, w komputerze popełniłem backup przez obraz partycji, następnie fsck (były błędy) i przy okazji zdjąłem journal z ext4. Podziałało jeszcze parę dni i sytuacja znowu się powtórzyła. Tym razem sprawdziłem dokładniej. Badblocks widzi błędy na karcie, zarówno na teście odczytu (jeden), jak i niedestrukcyjnym teście zapisu (więcej). Próbowałem reanimować przez oznaczenie przez fsck sektorów jako uszkodzonych (patrz przydatne polecenia Linux), ale bez powodzenia. Po naprawie rpi już się nie bootuje z tej karty.

Nie jestem w stanie stwierdzić, czy winien był – niestety domyślnie w Raspbianie włączony – journal, czy zapisywanie przez transmission stanu co kilkanaście minut na dysk (kartę) gdzieś w /var. Symlinka i przenoszenia na dysk twardy nie robiłem. Po pierwsze i tak system był z journalem, po drugie, chciałem zobaczyć, na ile to szkodliwe dla karty. Jak widać jest szkodliwe i karta potrafi paść w mniej niż pół roku. Co prawda widzę karty Goodram 4 GB za ok. 10 zł, ale nie widzę sensu w grzebaniu i ew. utracie danych.

Niebawem, po kupnie karty (tak się pechowo składa, że nic wolnego większego niż 2 GB chwilowo pod ręką nie mam), wskrzeszę system. Być może kupię docelowy dysk do kieszeni i wtedy zrobię od razu root montowany w trybie read only. Nawet jeśli nie, to od razu po instalacji zdejmę journal z ext4, prawdopodobnie zajmę się też od razu transmission…

Kiedyś pojawią się tu zdjęcia – leżą na dysku, który był podłączony do NAS, a nie chce mi się podłączać go bezpośrednio do kompa…

[1] Bo router to WRT54GL, który co prawda linkuje się na 54 Mbit bezprzewodowo, ale realnie komputery wyciągają ok. 20 Mbps. Po wpięciu na kablu nie ma problemu. W eterze umiarkowany syf, wybrany najlepszy kanał i tryb G only. Ogólnie 802.11n by się przydało, ale przecież router działa, a szczerze mówiąc nie sądzę, bym zobaczył różnicę – 20 Mbps to kosmos. Chociaż znajomi donoszą, że przy 802.11n poprawia się zasięg, więc pewnie się skuszę…

[2] Żadne tam nielegale, po prostu mały wkład w projekty open source. Seedują się netiso Debiana (trzy architektury), pierwszy CD Debiana (trzy architektury), t(a)ils, tego typu sprawy. Zresztą pisałem o tym już (uroki niechronologicznego publikowania notek).

UPDATE: W jednej z kolejnych notek opisuję, jak zrobić z maszynki z Linuksem router GSM/Wi-Fi. Z uwagi na niewielkie rozmiary i mały pobór energii Raspberry Pi nadaje się do tego bardzo dobrze.

Opublikowane w

Pamięci flash, czyli pendrive, microSD itd.

Czasem człowiekowi wydaje się, że coś wie i… no właśnie, wydaje się. Że są różne pendrive’y (czy tam ogólnie pamięci flash), to wiedziałem. Wiedziałem też, że mają klasy i poszczególne klasy odpowiadają różnym prędkościom zapisu. I tyle.

Niedawno od hrw dowiedziałem się, że to nie do końca tak, że parametrów jest znacznie więcej i że w praktyce mają one spore znaczenie przy stosowaniu karty jako nośnika dla systemu Linux. Bo jednak czym innym jest zapis filmu na FAT, a czym innym realne operacje na jakichś linuksowych systemach plików.

Ostatnio uruchomiłem grzejnik na starym pendrive, użyłem ext2 i zdarzyło mi się trochę ponarzekać na μblogu, że wolno działa i w ogóle. Dostałem odpowiedź, że minimalny cluster size dla nośnika flash powinien być 4k. Co przypomniało mi wcześniejszą rozmowę i skłoniło do zadania pytania jak sprawdzić cluster size? Co dość szybko przywiodło mnie do wpisu nt. optymalizacji systemu plików dla pamięci flash.

Zauważyłem, że blog do którego powyżej linkuję ma raptem trzy wpisy i to sprzed roku, więc ryzyko zniknięcia jest spore. Pozwolę sobie zacytować dla pamięci część dotyczącą analizy:

  1. Interesting parts of this result are the diff changes drastically at two places:
    1. from  8388608 (8Mb) to 4194304 (4MB): Based in example readme in flashbench, this indicates that there was no performance overhead reading two blocks over the 4mb boundary, but there was for 8mb boundary. The guess is then that the erasure block is 8mb large on my sd-card
    2. before 8192 and after. I would really like to know why there is a bump at 8k, but times after that are so much lower, so 8k is obviously some sort of boundary point.
  2. From this, I deduce two things,
    1. Ext4 should have a block size of 4k, and the “stride” value should be 2. This will cause ext4 to think that units of 2 blocks (8k) can and should be treated as one.
    2. Ext4 should have the stripe-size set to 1024. This value was calculated by taking 8M (guessed erasure block size) dividing by 8K (size of a stride, 2 times block size (4K)). This will (hopefully) cause Ext4 to try to align writes so that while erasure blocks are written continuously and make it avoid sub-block updates.

Część dotyczącą ustawiania początku partycji w fdisk:

First sector (2048-15759359, default 2048): 16384

Wraz z wyjaśnieniem, skąd to się wzięło:

Fdisk uses blocks of 512 bytes, so that means that we want to start at 8*1024^2/512 = 16384.

No i na koniec część dotycząca tworzenia samego filesystemu ext4:

Reformat the filesystem, this time with Ext4 with block size of 4k, without journaling, but with additional parameters to encourage Ext4 to do the right thing with respect to the erasure block:

mkfs.ext4 -O ^has_journal -E stride=2,stripe-width=1024 -b 4096 -L Fedora14Arm  /dev/mmcblk0p1

Na koniec dwa linki, które autor wpisu podaje jako źródła:

Zachęcam do lektury całego wpisu z którego pochodzą powyższe cytaty, bo powyżej są jedynie najważniejsze wyjątki, które bez kontekstu nie do końca w czymkolwiek pomogą.

Inny, prostszy (ale starszy) wpis o podobnej tematyce: http://linux-howto-guide.blogspot.com/2009/10/increase-usb-flash-drive-write-speed.html

No i dowiedziałem się, że pożyteczne narzędzie to flashbench (pakiet jest w Debianie unstable), że żaden ext2 dla nośników flash, tylko ext4 bez journala, za to z dodatkowymi opcjami, zależnymi od parametrów karty. I że nie tylko w przypadku SSD warto stosować alignment. Różnica prędkości między ext2 a ext4 po tuningu? Wg autora wpisu 8 razy szybciej dla małych plików i dwa szybciej dla dużych. Trochę mi wszystko opadło, ale za to wiem, co będę robić w weekend.

UPDATE: Trochę się pobawiłem i wyszło mi, że metoda pomiaru jest średnio dokładna. Albo pendrive zwalnia w miarę używania (w sensie „wykonana ilość zapisów”), albo reboot/hibernacja drastycznie zmieniają wyniki, albo nie wiem co jest grane. Bo zrobiłem test na FAT, potem na ext4 po dopasowaniu partycji (brak zauważalnych różnic), potem zabawa z ustawieniami ext4 i… między pierwszym testem na ext4, a końcowym, na identycznych parametrach ext4 były 4 sekundy różnicy. Przy podstawie 22 sekundy, więc prawie 20% wolniej. Zagadka. A ponieważ nie widzę zysku między FAT a ext4, to chęć do migracji ext2 -> ext4 gwałtownie spadła. Może kiedyś.

UPDATE2: Dodane cytaty z bloga. Bawiłem się trochę w optymalizacje/benchmarki na czterech różnych pendrive’ach. Tylko jeden zareagował pozytywnie na zmianę alignmentu (OK, bez wyliczeń było, po prostu początek partycji na sektorze 16384) i zmianę systemu na ext4. Przy okazji wyszło na jaw, że pendrive, który uznałem za wolny jest ok. 3 razy wolniejszy od pozostałych, niezależnie od ustawień.