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.

10 odpowiedzi na “Raspberry Pi jako NAS”

  1. Czy ja dobrze kojarzę, że RPi nie ma niczego poza USB i slotem na kartę SD? Boli brak złącza dla dysku, że aż zęby bolą ;o)

    Opis Twojej obudowy przeraził mnie trochę, mam nadzieję, że to wszystko lepiej działa i wygląda, niż ubrałeś to tutaj w słowa.

    Chłodzenie, a raczej jego brak – tragiczne. Dla dysku temperatura powyżej 40 stopni uważana jest za skracająca jego życie, a powyżej 50 za krytyczną – jak już robiłeś otwory to ja dałbym w górnym mały wentylator 12V puszczony na 7V, będzie wówczas bezgłośny (7V uzyskasz wpinając się między 12V a 5V).

    Nie wiedziałem, że karty SD tak szybko się poddają – swego czasu miałem postawionego NASa na FreeNAS’ie (bynajmniej nie w opcji Live/Embedded) na karcie CompactFlash marki PQI i gdy po ponad 3 latach sprzęt szedł między ludzi na karcie błędów żadnych nie było.

    A’propos Transmission to jest to straszny smok na zasoby i lubi mielić. Domyślnie dane lądują w /var/lib/transmission-daemon/downloads/ ale można to zmienić w pliku konfiguracyjnym parametrem „download-dir” i od razu przekierować na dysk zewnętrzny – tyle, że przy NTFS to chyba nierealne, w routerach z Tomato AIO gdzie też jest Transmission użycie procka skacze do 100% i czasem potrafi zawiesić system, po zmianie typu partycji problem w dużej mierze znika (nie jest idealnie, ale nie zjada 100% zasobów).

    A co do opasek, potocznie nazywa się je „trytkami” ;o)

  2. Zgadza się, USB i karta SD. No i ethernet jeszcze. 😉 Ale szczerze mówiąc przerabiam taki konfig od dość dawna w innym miejscu (Dockstar) i nie jest tak źle, szczególnie jak dysk to 2,5″ 5400 RPM. Znaczy odczyty w granicach 25 MB/s spokojnie wyciąga. Pod NAS gdzie głównym zadaniem jest leżakowanie danych – spokojnie wystarcza.

    Będą zdjęcia. Jest to partyzantka, ale IMHO lepsze od pajęczyny kabli.

    Ma być bez elementów mechanicznych i cicho. Kieszeń jest w etui ze sztucznej skóry, więc ma dodatkową izolację od rpi, którego procek jest u góry zresztą. To jest dysk 2,5″, laptopowy. One normalnie pracują w 50 C nawet (jak są w laptopie). 40C to dla niego komfort. A przy pracy w kieszeni – zależy, gdzie kto go postawi. Jak akurat w okolicy wylotu powietrza z laptopa, to nawet gorzej może mieć…

    Wentylator 80 mm nie wchodzi w grę, poza tym, byłby problem z zasilaniem. Musiałbym na 5V puszczać, ale nie widzę sensu, bo IMO temperatura jest OK. Co najwyżej dorobię jeszcze kilka dziurek „odpływowych”.

    Czasem życia karty też jestem niemile zaskoczony. Nawet bawiłbym się w odciążenie tego /var, gdyby był journal od początku zdjęty. Ale zorientowałem się po jakichś 2 m-cach, że nie jest. Plus syslog itp… Ogólnie uważam to za błąd Raspbiana (o czym pisałem w poprzednim wpisie na jego temat). PQI są IMO dobre. Mam znaleźny klucz USB, też długo działał (ale filesystem dostosowany) i miał w benchmarkach niezłe wyniki.

    W zasadzie wybierałem między transmission a rtorrent. Przy czym ten drugi nie ma fajnego lekkiego GUI w repo oraz… z tego co czytałem, jest cięższy (chociaż działał u mnie i na PII z 64 MB kiedyś i potem na różnych sprzętach ze 128 MB. Właśnie podobno transmission ląduje na różnych embedded typu NAS czy router ze względu na niskie wymagania. Ale przy większych plikach (1 GB to pikuś) pewnych rzeczy nie przeskoczysz…

    Co do katalogu z danymi (czyli downloads) to jak najbardziej był na normalnym dysku na NTFS. Do /var zapisywał „tylko” stany. I IIRC nie było na to opcji w konfigu (a z symlinkowaniem do NTFS nie chciałem eksperymentować).

  3. W konfigu Transmission jest jeszcze opcja „incomplete-dir” – podajesz tam ścieżkę do miejsca w jakim aplikacja może sobie mielić do woli, i jak już cały plik pobierze to sama go przeniesie do miejsca jakie zdefiniowałeś w „download-dir” – mam tak zrobione u siebie i /var/lib/transmission-daemon/downloads świeci u mnie pustkami :o)

    Jak chodzi o zasobożerność to niestety ale w Embedded często lądują stare wersje Transmission, z tego prostego powodu, że mają mniejsze wymagania niż te nowsze i nie wysypują się tak często. Stabilność tej aplikacji pozostawia wiele do życzenia, aż musiałem wyrzeźbić sobie skrypt sprawdzający w Cronie czy jest aktywny i w razie W automatycznie podnoszący zwłoki ;o)

  4. @Monter Nie, nie o incomplete-dir chodziło. Jak zreanimuję, to napiszę, ale nie widziałem opcji do tego w konfigu (a pobieżnie szukałem).

    Jeśli chodzi o stabilność, to na tych kilku plikach nie zauważyłem żadnych problemów na Raspberry Pi. Ale faktem jest, to nie embedded, a RAMu wręcz sporo, jak na takie zastosowania.

  5. Może chodzi Ci o foldery …/info/torrents i …/info/resume? W tym pierwszym lezą sobie pliki .torrent i nic się z nimi nie dzieje (są kasowane po pobraniu danego Torrenta (w przypadku ssania plików), w tym drugim faktycznie pliki są co jakiś czas aktualizowane, ale tu może pomóc usunięcie tego folderu i zastąpienie symlinkiem do zasobów dysku twardego, który jak mniemam chodzi w trybie 24/7?

  6. Tak, chodziło o /var/lib/transmission-daemon/info generalnie. Zrobiony symlink i zobaczymy… Przy okazji zmniejszyłem message-level z 2 do 1 i – zupełnie niezwiązane z transmission – odczyty temperatury (i zapisy do sysloga) zmniejszone z co 15 min na co 60 min.

  7. Transfer po wifi zawsze dzielimy na pół, ze względu na fakt, że mamy dwa „tory” czyli Uplink i Downlink, przez co pasmo jest dzielone na pół i w standardzie G więcej niż 27 Mbit/s w jedną stronę nie wyciagniesz. Po „N” jest różnie ale zasada ta sama, też dzielisz na pół a szybkość zależy od ilości rzeczywistych torów, dlatego by mieć link na 300 MBit/s trzeba dwóch anten i rzeczywiście w jedną stronę wyciągasz 150 Mbit/s

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *