SD kártyán futó Linux védelme

Linux-kezdő

Sziasztok

Adva van egy kis erőforrású hardver (vékonykliens vagy Raspberry Pi).
CF vagy SD kártyáról fog üzemelni, naponta max 4 órát lesz használva a szerkezet (utána akár offolható is lenne).
Üzembiztosan kell működnie, de aggaszt a véletlen áramszünet okozta fájlrendszer sérülés és, hogy ezután nem áll fel a rendszer. Annak pedig fel_kell_állnia mindig.
A read-only rendszer szinten még megoldható, de lesz rajta egy adatbázis, amit a 4 óra alatt sűrűn ír, olvas.
Adatbázisnak elvileg SQLite elég lesz.

A problémára a force fsck-t találtam (# touch /forcefsck), amit minden boot után létrehozok, így ha hírtelen power off, a fájl ott van, boot közben ellenőriz.
Szabályos leállítás során pedig a shutdown scriptek egyikével törlöm ezt a fájlt.

Aki foglalkozott már ilyesmivel, mennyire megbízható ez a megoldás?

Szünetmentes helyhiány és egyéb okok miatt első körben nem opció.

Előre is köszönöm a tippeket.

  • 6073 megtekintés

( wachag | 2013. 06. 04., k – 09:12 )

> CF vagy SD kártyáról fog üzemelni [...] amit a 4 óra alatt sűrűn ír
> mennyire megbízható ez a megoldás?

Semennyire.

( rts | 2013. 06. 04., k – 09:18 )

OFF: Minden körülmények között fel kell állnia... hmm ezzel a problémával minden férfi küzd :D
ON:
- SD kártyán egy terhelt adatbázis szerver? Biztos végiggondoltad ezt??
- Egyébként JFS

Hát a 4 óra alatt viszonylag sűrű írás. Persze egy hosting környezethez képest ez semmi, tényleg:)
Rendszer szintű írásokhoz képest viszont sűrű(bb) írásnak tekinthető.
Amúgy sajnos tudom, hogy kinyírható vele a kártya, erre 2 ötletem volna:
- Nagyobb méretű SD kártyát használok és bízok a benne lévő wear-level, írásterítés technikában.
- Ramfs-ben tárolom az aktív sqlite fájlt, amit időnként átrakok védett helyre (SD-re). Ez lehet egy partíció, ami alapból ro, de frissítés idejére rw-be kapcsolom + még is megoldom valahogy a szünetmentesítést, detektálom a 230V kiesést majd ilyenkor letárolom a ramfs-ben lévő adatbázist és lekapcsolom a gépet.

Lehet, hogy ez az utóbbi a legkíméletesebb. Így elvileg a teljes kártya ro-ban lehet.

Ha csak nincs valakinek jobb ötlete?

még is megoldom valahogy a szünetmentesítést, detektálom a 230V kiesést majd ilyenkor letárolom a ramfs-ben lévő adatbázist és lekapcsolom a gépet.

A szünetmentesítés jó gondolat, de a 220-at felejtsd el. Ez 5V-ról üzemel, egy 12V-os akku rálógatva egy töltőre, plusz egy 12V->5V DC-DC konverter tökéletesen megfelelő neki, és sokkal kevesebb veszteséggel jár, mint a 12VDC->230VAC->5VDC. Az ebayen találsz helyes kis áramköröket egy ezres körül, azok teljesen jók lesznek ide (step-down dc-dc converter néven kell keresni).

Az miért nem jó, hogy ha egy sima szünetmentesbe dugja vékonykliens tápját? a szünetmentes usb porton tud is szólni a kliensnek ha elvették az áramot, illetve le is állíthatja ha már kevés benne a delej.

szerk. lentebb már látom, a fogyasztás miatt nem jó a fent említett megoldás.

( Frantique v | 2013. 06. 04., k – 09:52 )

Egy bluetoothos vonalkódolvasóval és egy androidos telefonnal is meg lehet ezt csinálni, áramszünet megoldva, sqlite mehet a kártyára vagy a belső írható memóriába. Sőt, még vonalkódolvasó se kell, a telefon kamerája is lehet az olvasó. Tovább gondolva a projektet, az adatok frissítése és a backupolás távoli tárhelyre szintén megoldható egy scripttel is, sőt, még a Google Drive is segíthet a témában.

Ha ilyen kis terhelés a várható, tuti, hogy így közelíteném meg a problémát.

--
Coding for fun. ;)

Köszönöm a közös ötletelést, máshova jó lehet, de sajnos most számomra ez nem járható út.
Nem mondtam el a teljes projektet, mert a kérdés szempontjából nem érdekes, de lényeg, hogy androidos mókolások nem játszanak:)
Minimum kézi vonalkódolvasó lesz letelepítve konzollal, de kis ipari olvasó sem kizárt + tasztatúra és külső I/O vezérlés is lesz a buliban, tehát teló sajna nem az igazi.
Amúgy a szünetmentesíthetőség miatt egyre inkább RPi-re hajlok, csak abban az SD kártya csatlakozása aggaszt. Szerintem nem olyan megbízható, mint egy CF kártyánál az a sok tűs csatlakozó, ami ráadásul zártabb is amikor benne van a kártya.

Kiegészítés: net ugyan van, de nem megbízható a hálózat, tehát nem lehet rá építeni. A vékonykliens és a nap végi kezelő gép között közvetlen kábeles kapcsolat lesz. Tehát a rendszer igazából offline.

Ugyan ismertem ezt a lehetőséget, de nem játszottam el a gondolattal.
Jó ötletlen tűnik, oly módon, hogy a rendszer a kártyán legyen, a változó adatok (pl. adatbázis) egy pendrive-on.
Egy pendrive-ot bárki ki tud cserélni időnként, csak a háttérben fel kell rá készíteni a rendszert.
Elég esélyes megoldásnak tűnik, köszönöm.
Eellett a többiek javaslatára a szünetmentesítésre is nagyobb hangsúlyt fektetek.

Köszönöm a közös ötletelést mindenkinek!

( uid_4672 | 2013. 06. 04., k – 10:17 )

Nem megbízható. Ahogy írták: elhasználódik, nem bírja az áramszüneteket, sok lesz a filerendszer corruption, stb. Még ha márkásat használsz, akkor is.

Esetleg használhatsz egy külső usb-s ssd-t, ha nem drága. A Verbatimnak van Store 'n' Go névre hallgató cucca.

( zeller | 2013. 06. 04., k – 10:27 )

Az Rpi-nek nem kell nagy teljesítmény, azt szünetmentesíteni nem igazán nagy meló, "normál" nagy ups-ben ilyen esetben nem szabad gondolkodni - a legkisebb is közel annyit fogyaszt, mint maga az rpi.

( bzs v | 2013. 06. 04., k – 10:38 )

Slaxot használnék sd kártyán. Amit még tudok, azokat a fájlrendszeren tovább tömöríteném squashfs használatával. Majd wifikapcsolat, sftp, és a cucc oda ír adatot, nem a kártyára. A slaxokat meg lehet barkácsolni úgy, hogy semmit se írjon a kártyára. Írásvédetté is lehet tenni.
http://www.slax.org/hu/
---
--- A gond akkor van, ha látszólag minden működik. ---
---

Slackware ARM on the Raspberry Pi Devices:
http://slackblogs.blogspot.fr/2012/07/slackware-arm-on-raspberry-pi-dev…

Slax for ARM processors architecture:
http://old.slax.org/forum.php?action=view&parentID=79298

(A slax a slackware live verziója)

---
--- A gond akkor van, ha látszólag minden működik. ---
---

( asch v | 2013. 06. 04., k – 11:23 )

Adatbázis helyett lineárisan írnám az eseményeket, így eleve meg lenne oldva a wear levelling. A kártyára a gyártó adatai és a használat alapján számolnék élettartamot, és előírnám, hogy ennyi időnként cserélni kell a kártyát - pl a kütyü "szól" mikor már ideje cserélni. IMHO ez a legegyszerűbb, legolcsóbb és legjobb megoldás.

Köszönöm, megfontolandó ez is, akár ötvözve a többivel. El is feledtem, de most eszembe juttattad: a wear-levellinget az sql fájlok napi/heti mentésével, új nyitásával gondoltam manuálisan javítani, mivel esélyes, ha mindig csak 1 fájlt írok, ürítek, írok akkor a háttérben csak azt a néháy blokkot fárasztja.

( BognarB v | 2013. 06. 04., k – 15:10 )

Kicsit OFF.:

Az egyik kamerám SD-re menti az adatokat, több mint 1,5 éve megállás nélkül.
Mostantól nézegessem sűrűbben, hogy megy-e még? :)

Apropó, van rá valami smartctl szerű megoldás?

Köszi!

udv
letix
-----------------------------------------
Linux alapparancsok, kezdőknek