Ramback: gyorsabb a puskagolyónál

Kernel

Még nem jutottunk el arra a pontra, ahol a számítógépes rendszerek - beleértve a csúcskategóriás gépeket is - tömegével terabyte méretű memóriákkal szerelve érkeznek. Azonban ha figyelembe vesszük, hogy vannak már olyan gyártók, akitől ha van pénzünk, akár 500 GB memóriát tartalmazó dobozokat is vehetünk, akkor talán itt az idő elgondolkodni azon, hogy mit kezdünk majd ennyi memóriával, ha egyszer majd megengedhetjük magunknak. Főleg most, hogy a Firefox fejlesztők is egyre nagyobb gondot fordítanak a memóriaszivárgások felszámolására. Még a végén nem tudunk majd mit kezdeni a felesleges memóriával...

Itt van például a Violin Memory, aki óriási méretű memória dobozok, ún. Violin Switched Memory (VXM) eszközök építésével és árusításával foglalkozik. Talán tényleg itt az ideje a tervezésnek.

Daniel Philips neki is állt nagyot álmodni. Egy olyan, Ramback névre hallgató patch-et készített a Linux kernelhez, amely az adott memóriát ramdisk-ké alakítja, de oly módon, hogy mögé tesz egy tartós adattárolásra képes eszközt is. Normális esetben az összes alkalmazás IO művelete a ramdisk-ben zajlik. Ennek előnyét magyarázni nem kell, mivel a műveletek memóriában történnek, a merevlemezhez képes "egész gyors" lesz. A szerző szerint az átlag tesztekben egy 25 másodperces fileművelet a sync-kel együtt 1 másodperc alatt lezajlik. A ramdisk hátránya, hogy az adat csak addig marad meg benne, amíg a gépet ki nem kapcsoljuk. Éppen ezért kerül mögé a perzisztens adattároló eszköz. A háttérben a kernel gondoskodik a gyors ramdisk és a lassú merevlemez vagy egyéb adattároló eszköz közti szinkronizálásról.

Nem vitatta senki, hogy a Ramback gyors, azonban voltak akik aggódtak az adatintegritás miatt. Normális működés esetén a ramdisk és a mögötte található jóval lassabb, tartós adattároló eszköz nincs szinkronban. Felvetődött, hogy mi van áramszünet esetén. A szerző szerint jó UPS kell a gép alá. Áramszünet esetén az UPS jelzésére a Ramback képes writeback módból writethrough módba kapcsolni. Ilyenkor az összes dirty adatot azonnal kiírja a lemezre és a következő írásokat azonnal a háttérben dolgozó lemezre irányítja.

Volt akiket nem ez a magyarázat győzött meg, azonban a fejlesztő bátor tesztelőket keres az elképzeléséhez.

Referenciák:
Ramback: faster than a speeding bullet
Kernel space: How to use a terabyte of RAM
Kapcsolódó LKML szál

( STP | 2008. 03. 20., cs – 19:34 )

Az Intel új üdvöskéjéről, a PRAM-ról nem az a hír járja, hogy nem veszíti el tartalmát áramkimaradás esetén sem?

PRAM nem adatvesztő memóriafajta, viszont minden egyes irásnál mechanikai folyamat zajlik le a memórián belül, emiatt várhatóan a sebessége a hagyományos RAM-okhoz képest lassabb, és az élettartama pedig véges lesz.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( turul16 v | 2008. 03. 20., cs – 19:43 )

Mostansag azon filoztam, hogy az osszes tmp komnytaramat egyteln nagy tmpfs-re iranyitom, swapomat meg fel turom az egebe.
De egy kerdesem adodott, szeretnem azt is, ha sok cache teruletem lenne, ezert ki kene talalni valami jo szabalyzast a swapelodesre

tmp -t rebootkor ugy is torolni kell, a tmpfs -el erre sem lenne gondom :)

Uppsz. Azt hittem 50 a default érték (nálam 30 van beállítva). 1000 bocs és két anyamedve... 8)

Ha jól tudom, akkor a kernel először a legrégebben használt tmpfs-en lévő fájlokat swappolja, és csak utána a többi memóriát. Viszont leíró részek maradnak cache-ban.

Itt magyarázzák (3. bekezdés) is, de most épp túl sokat ittam, hogy rájöjjek jól értem-e... 8)

Ha ismered a Slackware-t, ismered a Linuxot.

( lacika v | 2008. 03. 20., cs – 20:05 )

Még nem jutottunk el arra a pontra, ahol a számítógépes rendszerek - beleértve a csúcskategóriás gépeket is - terabyte méretű memóriákkal szerelve érkeznek.

Na, ez így nem teljesen igaz. Pl. M9000 vagy E25K.

--
http://laszlo.co.hu/

( saxus | 2008. 03. 20., cs – 20:06 )

Nem erre szolgálna többek között a cache, hogy a szabadon lévő memóriát a fájlműveletek gyorsítására használja? (Win-n legalábbis Windows Internals szerint így van). Egy-egy virtuális gép újraindításakor szépen meglátszik sebességben.

Csupán megkérdeztem, hogy mire van akkor a cache (linuxon), ha nem kb. ugyanerre? Különbség így első ránézésre annyi, hogy ez nem írja vissza azonnal az adatokat a lemezre, hanem a memóriában tárolja, ameddig lehet (pl. UPS jelzésig).

Virtuális gépeket meg azért hoztam példának, mert egy OS bootolása viszonylag komplexebb folyamat és eléggé látványos sebességkülönbség van akkor, mikor másodszor indítom el ugyanazt a rendszert és ez ugrott be elsőnek példának, azon ne kezdjük már el a win32 flame-t, mert eléggé offtopic.

( mcbuddha | 2008. 03. 20., cs – 20:28 )

Notebookok eseten ugyebar az akksi UPS-kent nagyon jol mukodik, igaz, ott nem is fordul elo ekkora RAM.

( poliverzum | 2008. 03. 20., cs – 21:19 )

Én azonbnal jelentkezem tesztelésre, ha ingyen adja hozzá a gépet...

Mitől is van olyan érzésem, hogy ez nemn fog bekövetkezni... Kár pedig.

Különben, régi fixa ideám, hogy a memóriáé a jövő, s a lemezes-szalagos stb, szóval mozgó eszközökre épülő adattárolás ideje le fog áldozni. Szóval a fickónak alapvetően szerintem igaza van.
-------------
:::A GoboLinux felhasználók hivatalos magyar fóruma: http://linux.birodalom.net/smf
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

( Elbandi v | 2008. 03. 20., cs – 22:24 )

hat en nem igazan ertem a sirast az aramszunet miatt. Tegyuk fel hogy egy progi kiirt egy fajlba egy A-t, majd egy B-t is, utana elment a villany. Namost ha van ez a ramback, akkor a progi kiirja az A es B-t, de megint elmegy az aram. A rambacknak meg volt annyi ideje, hogy A-t a diskre is kiirja, de B-t mar nem. Tehat az hogy az elso esetben B is lemezre irodott pusztan annak koszonheto, hogy nem 3 sec-el korabban lett aramszunet.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Másutt van a gond. Pl. a tranzakció látszólag lemegy de még valójában nincs kiírva az állandó adattárolóra. És itt jön az áramszünet. Van egy visszaigazolt tranzakciód de ténylegesen nincs meg.

Ezt egy módon lehet megoldani, a számítógép tápegysége tartalmaz egy akkumulátort (fél Farados kondi?), ami még 3-5 másodpercig ad villanyt és egy jelkábelt, ami egy interrupton keresztül jelzi a kernelnek, hogy gáz van, az dob egy-két nagyfogyasztót és még a villanyoltás előtt kitolja az adatokat a merevlemezre.

Vettem részt olyan projektben itt Magyarországon, ahol külön épület volt a gázturbinának, ami szükség esetén az egész kócerájt elhajtotta akár napokon keresztül is. Nem konnektorok voltak abba kötve ha jól emlékszem, hanem az egész mindenség. De ennek majd utánanézek. Nem csak bowdennel berántható 50 köbcentis mókák léteznek ám.

--
trey @ gépház

annó melóztam a B.A.Z. megyei Rendőr Főkapitányságon, ott volt egy autó méretű aggregátor ;-)

képzeld el a szitut, hogy a kedves állampolgár épp hívja a 112-t (vagy 107-et) és azt mondja a telefonja, hogy a hívott szám átmenetileg nem kapcsolható, mert nincs áram :-)

--
by Mikul@s

:)
Látom magam előtt, hogy miután beröffen a generátor felsikít a tintasugaras nyomtató monoton, fülsértő hangja és megkezdődik a piciny memóriatartalom kinyomtatása leporellóra... Amint a hibát elhárították Gizike a cég mindenes titkárnője nekiáll egy terminál előtt begépelni az 500TByte-os memória utolsó rögzített tartalmát bit-by-bit. :) Egy-egy ilyen recovery alig tartana több ideig mint néhány százezer év egy megfelelően eltökélt és munkája iránt elkötelezett Gizikével.

Ilyen megoldásokkal rengeteg munkahelyet teremthetünk! Képzeljétek el a felvételit: Miért gondolja, hogy ön a legalkalmasabb arra, hogy hiba nélkül bepötyögje az 500TByte-os memória tartalmát? :)

Tegyük fel, hogy van 1 TB memóriám, amiben megvalósítom ezt a Ramback-et. Bootkor indításkor betöltöm a kedvenc adatbázisomat a lemezről a buzi nagy memóriába. Mondjuk legyen ez a HUP adatbázisa. Az jelenleg kb. 1 GB, úgyhogy belefér. Marha gyors lesz az egész, hiszen nem lemezről kapod az adatokat, hanem memóriából, nem lemezre ír az adatbázis kezelő, hanem a memóriába. Átlagban 25-ször gyorsabb a memóriában lezajló művelet, mint a merevlemezen, azaz a merevlemez nem fog tudni lépést tartani a memóriában bekövetkező változásokal. Azaz tud, de folyamatos szinkronizálás esetén is csak 25-ször lassabban. Azaz egy áramszünet esetén - ha nincs UPS-ed - akkor elbuktad azokat változásokat, amit nem tudtál kiírni a lemezre. Ez a HUP esetében lehet, hogy csak néhány post, de egy kritikusabb rendszernél néhány milliós tranzakció is lehet. Mondjuk a fizetésed átutalása. :))

Ha van UPS-ed, akkor amikor elmegy az áram, a Ramback azonnal kiírja a lemezre a memóriában levő olyan adatokat, amik nincsenek a lemezen, majd átkapcsol egy olyan üzemmódba, hogy nem keletkezik dirty adat, mert minden változás azonnal megjelenik a lemezen is. Majd ha visszaállt a normális állapot, akkor a visszaállhat a memóriába dolgozás is újra.

--
trey @ gépház

( BaT | 2008. 03. 21., p – 01:01 )

Amúgy mennyi a puskagolyó adatátviteli sebessége? Én azt hittem, az is kiderül a cikkből. :)

És akkor már ide illik ParadoxH aláírása: "Sose becsüljük le egy autópályán szágúldó, kazettákkal megrakott furgon sávszélességét!" A. S. Tanenbaum

( Hunger | 2008. 03. 21., p – 01:32 )

Főleg most, hogy a Firefox fejlesztők is egyre nagyobb gondot fordítanak a memóriaszivárgások felszámolására. Még a végén nem tudunk majd mit kezdeni a felesleges memóriával...

LOL :))

Két éve tesztelgettünk olyan RamSan eszközöket, amelyek szintén fel vannak ruházva nagy mennyiségű memóriával és egy olyan elektronikával, amely áramkimaradás esetén az adatokat gyorsan egy merevlemezre írják. Akartam írni belőle anno egy cikket, csak mindig közbe jött valami...

A legkisebb típusról (RamSan-120) készített képeket most már legalább köreadom, ha már a témába vág:

http://hunger.hu/ramsan/

( emberk | 2008. 03. 21., p – 07:31 )

Nekem a nagy álmom egy szilárdtest winchester összerakása (szóval egy rakat ram, + egy áramkör, ami tartja a töltést. Tök könnyű lenne full format :D ). Ha már ekkor több Gb-s memóriák léteznek akkor veszek egy marékkal, és egy vezélő kérdése egy 64-bites proci iszonyú mennyiségű memóriát tud megcímezni. Nem is kellene belőle olyan nagy pocesszor. Csak hát kelle egy cég aki ezt finanszírozz, és támogat mert egyedül tuti lehetetlen ennek nekiesni, és megoldani. De ez annyira tök egyszerű ötlet, hogy a nagyoknak már biztosan eszébejutott.

( chrono | 2008. 03. 21., p – 08:49 )

Milyen vicces lesz majd nagypapa korunkban olvasgatni az ilyen híreket: az AMtel bejelentette új 1024 magos 1TB L2 cache-sel rendelkező low-end karórákba szánt belépő szintű processzorát.

( ambro | 2008. 03. 21., p – 09:14 )

Idézet a cikkből: "Normális működés esetén a ramdisk és a mögötte található jóval lassabb, tartós adattároló eszköz nincs szinkronban."

Szóval a cikk írójának fogalma sincs arról, hogy mi miért történik. Ugyanis az idézet mondat, mint a probléma középpontja egy ostobaság. A megálmodott és felettébb kívánatos rendszer ugyanis úgy működik, hogy egy írásvédelemmel ellátott és lezárt tartós adattároló eszközről (pl egy SD-kártya) történik a bebútolás, majd ezt a felállt rendszert akár évekig használhatjuk anélkül, hogy újra kellene bootolnunk. Kikapcsolás helyett ugyanis alvó állapot van. Notebookunkat sohasem hagyjuk áramforrás nélkül. Ha mégis, akkor bútolunk megint. Ennyi. Vagyis nincs itt a világon semmi probléma sem. Remélem minél előbb lesznek majd ilyen notik. Nekem is kell egy ilyen!

"Ettol fuggetlenul a ramdisk es a mogotte levo lassu hattertar tenyleg nincs szinkronban,"

Én ezt így fogtam fel. Ha szinkronban lenne, akkor mi szükség lenne az egész bohóckodásra? Az azt jelentené, hogy diszkműveletek olyan gyorsak, mint a RAM-ban végbemenő műveletek. Semmi értelme sem lenne.

--
trey @ gépház

Te miről beszélsz ember? Miért kellene szinkronban lennie? Nem elmagyaráztam, hogy a bebútolás lehet csak évente egyszer történik meg? Arra az egy alkalomra nem mindegy, hogy az a folyamat mennyire gyors, vagy mennyire lassú? Más köze nincs egymáshoz a két memóriának. Én nem tudom, hogy ezt miért nem lehet felfogni. :-(

És mi az hogy UPS hiba? Egy notinál ez nem értelmezhető. Legfeljebb ha tökre lefogyasztom az aksit, vagy működés közben kiveszem. De ezek egyike sem a normális működésből adódó probléma. Más szavakkal: nagyon hülye kell legyen a kezelő ha ilyesmit elkövet. Ha pedig ennyire hülye, akkor ott amúgy sem értelmezhető semmiféle adatbiztonság. Érted ezt?

Van a gyors RAM, ahol minden tortenik, meg van a lassu hattertar, ahol csak ritkan tortenik valami. Vegzel egy fajlmuveletet, mondjuk elmented a munkadat. Az bekerul a RAM-ba. Beut a az aramszunet (tokmindegy, hogy miert). A munkad csak a RAM-ban volt, mert meg nem szinkronizalta a kernel a hattertarral. A munkad elszallt. Ilyen egyszeru.

És mi az hogy UPS hiba?
Az, hogy az UPS is meg tud hibasodni. Vagy peldaul ha takaritas kozben kirantod a gepbol a tapkabelt. Nem megengedheto, hogy egy ilyen esemeny adatvesztessel jarjon.

Egy notinál ez nem értelmezhető.
Nem csak notik vannak a vilagon.

Roviden: a ramback csak addig jo, amig van aram. De ha csak 10 evben egyszer nincs aram, lottek az mindennek, ami egesz egyszeruen nem elfogadhato.

"A cikkben felvázolt patch által megvalósított megoldásról, vagy másról."

Miféle cikkben? Az eredeti angol nyelvű híradásokban, vagy a te általad írt félreértelmezésben? fenntartom a jogot, hogy egy cikk mögött az eredeti értelmet keressem, ne pedig a buta félremagyarázást. És megkérlek azzal kötekedj aki veled egy súlycsoportban van. Nem szeretném, ha egy nagyon is korrekt válaszom miatt te -érdemi válasz híján-, indulatból kitiltanál. Értve vagyok?

"Miféle cikkben?"

Őőő, a Referenciák alatt felsorolt három linkre gondoltam. Segítek:

Ramback: faster than a speeding bullet
Kernel space: How to use a terabyte of RAM
Kapcsolódó LKML szál

És hogy hol kezd:

"So now you can ask some hard questions: what if the power goes out
completely or the host crashes or something else goes wrong while
critical data is still in the ramdisk?"

"Értve vagyok?"

Hogyne. Rég megtanultam, hogy vannak emberek nem szabad ellenkezni ;)

--
trey @ gépház

Kétszer kérdeztem meg, hogy miről beszélsz. Megkérdeztem, hogy elolvastad-e a Ramback patch-ről szóló bejelentést. Erre választ nem adtál választ, csak fújtad tovább a dalodat. Valószínűleg nem egy dolgoról beszélünk. Jövőbeli fejlesztésekről hadoválsz, pedig itt nem arról van szó. A cikk pedig egy konkrét, most kipróbálható, kézzelfogható, a Linux kernelhez készült patch-ről és annak esetleges problémás részeiről szól. Tehát utoljára a kérdéseim:

Elolvastad a patch bejelentéséről szóló postot?

"Ramback is a new virtual device with the ability to back a ramdisk
by a real disk, obtaining the performance level of a ramdisk but with
the data durability of a hard disk. To work this magic, ramback needs
a little help from a UPS."

Erről folyik a diskurzus. HTH.

--
trey @ gépház

Abban az egyben van igazság, hogy a RAMback már ma használható laptopokon, ha a felhasználónak van annyi esze, hogy ha nincs áram és kicsit az akksi töltöttsége, akkor lekapcsolja a gépet.

"Mindössze" olyan laptop kéne, amibe lehet pakolni rendesen RAMot (azért 8G nekem már elég lenne... :-)

---
"A hülyeségen nem segít a linuz." (BE)

Amirol te beszelsz a mezi ram disk hasznalta. Ma is hasznaljak ilyen cellal.
Gonosz modon initrd megadod a fs -t amirol bootolni akarsz az bemasolodik a ramba es ott marad, majd elfelejted a real init -et meghivni es keszen vagy. (Lealitaskor ezt ram disket is el dd -ezheted valahova.)

Ez a rendszer mas, itt van egy valos blokk device mogotte folyamatosan, ahova folyamatason kerulnek vissza az adatok, de nem feltetlen olyan gyorsan, mint ahogy azok valtoznak. Egy folyamt foglalkozik azzal, hogy gyujtogesse (dirty blokkokat). Mivel a rendszer, nem fs szinten gondolkozik, hanem mondjuk 4k lapokban, igy aramszunet eseten orisai baromsagok maradhatnak az fs -en, inkozisztens lesz.

ja, es meg egy dolog, ez hasznalhato a ramdisk -be masoloas kozben is, nem kell megvarni a teljes ramba toltodest.

( mcbuddha | 2008. 03. 21., p – 09:53 )

Es akkor divatba jonnek a CF-IDE megoldasok meg az SSD-k, mert igy gondolom toredekere csokkentheto a flash memoriat megviselo irasok szama.

( uid_1526 | 2008. 03. 21., p – 11:23 )

Én ott látom a problémát a megvalósításban, hogy a szinkronizálás szoftveresen menne. Az áramkimaradás szünetmentes megoldások használatával nem okozhat gondot, viszont ha a rendszer magába zuhan, akkor ott már nem lesz semmilyen szinkronizálás. Ezt a funkciót szerintem érdemesebb lenne hardveresen megvalósítani, nem az oprendszer részeként.

Pedig az elgondolas nem rossz, egy atlag User eseten, sot servereknel is lehetne jo, a hozzaferesek gyakorisaganak figyelesevel... van par terulet (pl amiben en is dolgozom), hogyha olyan gephez jutnek, amiben 1-2-xTB RAM van, en hagynek mindent hagyomanyosra, es csak azokat az adatokat toltenem fel, RAM-ba, esetleg a software-t amivel eppen dolgozom... Nem tudnak kitalalni olyan gepet, amit szet ne terhelnek...
de gondoljuk csak vegig... volt a DOS... 4Mega ram-al a kezdetekben isten voltal, aztan kellet mar a 8Mega a Dark Forces miatt (akkoriban meg csak jatszottam, de akkor mar elkezdtem programozni)... aztan jott a Win95, es linuxos X-ek... azert annak kellet a tobb, mar talan 32Mega is ... :D
igy mentunk feljebb, emlexem meg win9x-es idoben, 128Mega ram... aztan 1Giga, 2 Giga... most 4Giga ram-om van... mindig azt hittem, hogy nah ez untig eleg mindenre... aztan hamar belefutottam, hogy nem...
jo tudom, en elegge extrem modon hasznalom a computerem, 3d-vel, reklamokkal, filmekkel, latvanytervekkel foglalkozom...
de akar egy tudosnak is szuksege van ilyen teljesitmenyu gepekre, sorolhatnank a teruleteket, csillagaszat, biokemia...
a masik, hogy mig egy win3.1-nek szinte alig kell ram, addig mar a Vistaba mennyi kell, es azert Linuxos desktop kornyezetek is eszik a ramot, ha osszehasonlitjuk a win3.1-es idobeliekkel... ezzel csak azt akarom mondani, hogy egyre csillivilibb a Desktop, es egyre tobb eroforrast igenyel, es higgyetek el, ha azok alatalanosak lesznek, akkor mar az OS-s is eroteljesen fogja hasznalni...

A Dos 1MB rammal is "király" volt, sőt, afelett már nem is kezelte egyszerűen. A win95 elnyekergett 4 megával, inkább 8-cal. Azon a környéken sose volt normális memoriakezelés, de ez más téma.
Van egy összeesküvéselméletem, miszerint a szoftver-és hardvergyártók között létezik legalább egy hallgatólagos megegyezés: csinálunk behemót, erőforrásigényes szoftvereket, ti meg csináltok a mi rendszerünkhöz drivereket. Mindenki jól jár, csak a júzer nem. Szó sincs igények kielégítéséről, inkább igények gerjesztédéről. Aztán ha véletlenül mégis igény lenne megbízható, terhelhető rendszerre, akkor csak a fud marad. Szánalmas dolgok történnek mind a hardver, mind a szoftverfejlestésben úgy általában. Reménykedem, ez a nyílt forrású rendszerekre ez nem lesz ilyen sarkítottan igaz. Az architektúra meg adva van, azt nem lehet házilag átírni...

A Dos 1MB rammal is "király" volt, sőt, afelett már nem is kezelte egyszerűen.

Sőt, már 640k felett sem. :)

Reménykedem, ez a nyílt forrású rendszerekre ez nem lesz ilyen sarkítottan igaz.

Gondolom tömegével használsz nyílt forrású rendszereket még mindig 4-8 megával... ;)

avr32 cuccal talalkoztam amiben 8 Mb ram volt.
mplayert sikerult beizatani, alatta :), 2.6 -os kernel mellett, Talan 4Mb volt szabad RAM, miutan shell is ment, leszogezem nem fekudtem ra a lecsupaszitasra.

A memoria igenye a kernelnek rohamosan novekszik. 2.2 kb 1/4 megatol el van. 2.4 ikabb fel mega felett. 2.6 1Mb felett.

Es beagyazott rendszereknel, ha gyors a rom/flash amiben kernel nyugszik, lehet execute in place-t tolni, es akkor ram be at sem toltodik.

( hrgy84 | 2008. 03. 22., szo – 04:41 )

Egyes Phoenix BIOS-ok is tudtak hasonlokat laptopokba. Kellett egy specko part, es ennyi.

( turul16 v | 2008. 03. 23., v – 14:48 )

ccache -hez lehetne hasznalni kisebb memoriaval is.