Reiser4: mi legyen a sorsa?

Fájlrendszer, NAS, storage

Pár napja megjelent a Reiser4 filerendszer az Andrew Morton féle -mm kernelfában.

Ezzel kapcsolatban egy nagyon-nagyon hosszú szál indult az LKML-en. A beszélgetés akörül forog, hogy a Reiser4 beolvasztása olyan változásokkal bővíti ki a a Linux kernel API-t, amelyet POSIX/Unix/stb. specifikációk nem láttak előre. Hans Reiser természetesen azt szeretné, ha a Reiser4 mihamarabb a kernel része lenne.Andrew Morton ennyire nem siettetné a dolgot. Reiser szerint muszáj beolvasztani a Reiser4-et, mert a Microsoft-féle WinFS és Dominic Giampaolo által készített Spotlight már nagyon közel van a megjelenéshez, így kell valamit produkálni válaszul.

Reiser szerint szükség van arra, hogy kereső motort (search engine) és adatbázis funkcionalitást építsenek a filerendszerbe. Ahhoz, hogy ezt meg lehessen tenni egy tiszta tároló réteget (storage layer) kell tervezni, amelyhez 11 évnyi komoly munkára van szükség. A Reiser4 már most tudja ezt. Ezt egyik linuxos filerendszer sem tudja jelenleg. A ReiserFS következő nagy kiadása már nagy ugrás lehetne, mert az előfeltételek már a helyükön vannak a Reiser4-ben. Reiser arra kéri a fejlesztőket, hogy ne tegyék a Reiser4-et a VFS-be, hanem használják a Reiser4-et, mint VFS-t. Ne írjanak újabb filerendszereket, hanem írjanak file plugin-okat és diszk formátum plugin-okat a Reiser4-hez. Arra kéri a fejlesztőket, hogy értékeljék 10 év munkáját, és ne duplikálják a meglevő dolgokat, hanem használják azt, ami már készen van.

Mivel az egész Reiser4 egy nagy témakör Andrew Morton szerint is, arra kérte Hans Reisert, hogy szedje össze azokat a dolgokat, amelyeket a fejlesztőknek mindenképpen tudniuk kell róla. Például írja le, hogy miért jobb a plugin formátum, mint az a megoldás, amelyet a jelenlegi filerendszerek használnak.

Resier szerint ha valaki a jelenlegi filerendszerekkel akar foglalkozni, akkor annak kb. 6 hónapjába kerül, mire annyira képbe jön, hogy változtatni tud bennük. A Reiser4-hez plugint írni hétvégi programmer feladat...

A KernelTrap összeszedte a több száz levélből álló thread lényegét. El lehet olvasni itt. Az LKML szál (erős idegzetűeknek) itt kezdődik.

( mogorva v | 2004. 08. 28., szo – 22:22 )

Konyorgom meselje mar el vki, minek nekem a filerendszerbe keresomotor? Meg adatbazis funkcionalitas??? Azert, mert az MS kitalal valami kretenseget, nem kell mindenaron utana menni. Ettol fuggetlenul a reiserfs biztosan rulzik, tehat nem azzal van a bajom.

mogorva

( Névtelen (nem ellenőrzött) | 2004. 08. 28., szo – 22:34 )

Én egy hete tértem át Reiser4-re. Az otthoni Gentoo Linux-ot futtató gépem root partícióján eddig stabilan működik. A grub patch-et nem próbáltam, helyette ext2-re tettem a /boot részt.

Teszteltem a tömörítetlen kernelfa untar-olásával, másolásával és törlésével. A reiserfs 3.6-tal vetettem össze. Pontos adataim nincsenek, de emlékszem a főbb eredményekre:

* az untar azonos időben végzett a reiser4-en és a reiserfs-en is

* a másolás 3x gyorsabb volt reiser4-en

* a törlés 2x vagy 3x lassabb volt reiser4-en

Ahhoz képest, hogy a sebesség tuningolását későbbre ígérik szerintem már most a leggyorsabb fájlrendszer Linux alatt.

( cstamas | 2004. 08. 28., szo – 22:57 )

Ha most beteszik, akkor megint megbolydul a "stabil" kernel.

Ha nem teszik be, akkor valami komoly fejlődésről maradunk le. (IMHO)

Bár az is lehet hogy eltávolítanak egy-két hook-ot hogy megnehezítsék a feladatokat. :-§

probálj meg egy 3 TB os disken rendet tartani

a keresőmotor azt a célt szolgálja hogy azt mondod hogy kellenek a leveleid és nem érdekel hol vannak de kellenek

pl kell email

erre a filerendszered kidobja neked az leveleidet

de te nem tudod hogy ezek pontosan hol vanna k. de lényegében nem is érdekel mert sokkal gyorsabban megkapod őket mintha

cd /home/u/user/mail/Munka/mail

ben megkeresnéd

ez egy sarkallatos példa

de a terrás winyokon nem tartható a könyvtárrendszeres megoldás hatékonyan

Egy kis megjegyzés: az untar-t .tar.bz2-ből csináltad vagy előtte külön kitömörítetted a .tar-t?

Mert ugyanis, ha .tar.bz2-ből csináltad, akkor a bzip2 kitömörítés (ami hihetetlenül lassú!) miatt tart annyi ideig, a fájlrendszer csak minimálisan befolyásolja a dolgokat. Arról nem is beszélve, hogy a bz2 kitömörítés nagy CPU igényű, tehát az olyan fájlrendszer, aminek nagy a CPU overhead-je (a Reiser4-nek toronymagasan a legnagyobb) hátrányba kerül. Még akkor is, ha egyébként jól optimalizálja a merevlemez seekeléseket. Az más kérdés persze, hogy gyakorlatban az ember mindig tömörített tarból pakolja ki a forrást...

A másik: ilyen benchmarkokat én is csináltam még korábban http://home.sch.bme.hu/~xmi/newresults_WD64_summary.html [home.sch.bme.hu], de az az érzésem, hogy hamis -vagy legalábbis félrevezető- eredményeket ad. Ezeket ugyanis frissen mkfs-elt fájlrendszeren méri az ember. Azt sokkal fontosabb volna megtudni, hogy hogy viselkedik, több hónapnyi használat után (rendszeres csomag upgrade-elés, rendszeres file törölgetés, új fájlok letöltése, módosítgatás stb) mennyire fragmentálódik szét az egész. Lehet ugyanis, hogy ami ideális körülmények között kiemelkedően jó, az valódi használati körülmények esetén legfeljebb középszerű teljesítményt nyújt. (A reiser3-mal kapcsolatban határozottan van olyan érzésem, hogy jelentősen degradálódott a teljesítménye)

A probléma az, hogy ilyen tesztből nehéz reprodukálható összehasonlítást végezni. Mostanában dolgozgatok ki valamiféle brutális fájlrendszer-trashing scriptet. Elég sok a szempont:

- legyen kellően durva, hogy hosszú normális használatot tudjak rövid idő alatt szimulálni

- legyen reális, tehát hasonlítson nagyjából a normális használati mintákhoz

- legyen reprodukálható, tehát ne legyen benne semmi ténylegesen random, azonos fájrendszeren és azonos gépen mindig ugyanazt az eredményt adja

- legyen érdekes (releváns) az eredmény, ne csak valami szintetikus pontszám legyen

Na meg még egy érdekes kérdés merült itten fel! Az egyes fájlrendszerek sebességét hogyan befolyásolják a különféle io ütemezők?

Optimalizálja a seekeléseket a filerendszer is,

optimalizálja a seekeléseket io ütemező is;

na ebből aztán mi sül ki, azt még a fejlesztők sem tudják... :(

Van most jelenleg a kernelben 5 általános célú (tehát nem vfat, ntfs, iso, meg hasonlók) fájlrendszer. (Jelen esetben az ext2-t és az ext3-mat egynek tekintem, a jorunaling csak üzemmódbeli eltérés)

Mindegyiknek vannak különféle üzemmódjai, ha mindegyik fs összes lényeges üzemmódját le akarom tesztelni, akkor az legalább 10 tesztelni való. (Egy másik benchmarkomban [home.sch.bme.hu] össze vannak szedve, csak a reiser4 hiányzik.)

Van most hány IO ütemező is? 4 féle, ha nem maradtam le semmiről (beleértve a noop-ot is). Ez azt jelenti, hogy 40 féle kombinációt kell letesztelni, ha teljes képet akarunk kapni. És akkor még semmit beszéltünk arról, hogy miből álljanak a tesztek. Nyilván nem elég egyféle teszt, nagyon sok kell. Ezeket a teszteket ráadásul illik többször megismételni, hogy lássuk mennyire konzisztensek az eredmények, és persze átlagolni az értékeket. És akkor még mindig van, ami kimaradt: hogyan függenek az eredmények a hardvertől? Mi számit sokat? Mivel skálázódik jól a teljesítmény? A gyors CPU? A sok RAM? A vinyó mérete? fordulatszáma? seek ideje? átviteli sebessége?

Még végiggondolni is sok mindezt. Egy élet nem lenne elég arra, hogy ezt mind végigmérjük. Arról nem is beszélve, hogy hogyan vizualizáljuk az eredményeket? A rengeteg eredményből le fogunk-e tudni valami okos következtetést vonni?

Mi ebből a tanulság? Nem tudom. Valószínüleg az, hogy nyakunkon egy csomó fejlesztés, egy csomó alternatíva, amikkel alig érünk valamit, mert fogalmunk sincs, hogy ténylegesen melyiket érdemes választani. És ha nem tudunk egyértelműen rámutatni, hogy ez jó, az meg rossz, akkor nem tudjuk kidobálni a rosszakat, tehát ez a káosz nem fog rendeződni.

Na mindegy elmegyek inkább aludni a filozofálás helyett...

A Linux-ot többek között az alternatívák miatt szeretem.

Az LKML-t, a linux-xfs és a reiserfs levlistákat olvasgatva szoktam dönteni, hogy mit használjak. Utána letesztelem a fájlrendszert, és ha én is látom, hogy gyorsabb, akkor áttérek rá. A reiser4-re már régen felfigyeltem. Kezdetben mindig lefagyott, de egy ideje már stabil.

Így a tesztelések alatt mire jutottál, melyik IO-ütemező a legjobb?

Az anticipatory, a deadline vagy a cfq? Én a default anticipatory-t használom, érdemes bekapcsolni a cfq-t bootoláskor?

Én egy kicsit más véleményen vagyok. Közeledik azért a mágneses adattárolási sűrűség elvi határa; az alternatív tárolási eljárások pedig még eléggé gyerekcipőben járnak. Gondolok itt pl.: az IBM-féle Millipede rendszerre, de említhetném a flash memóriákat is.

Szerintem szép fokozatosan le fog lassulni a merevlemezek kapacitásnövekedése két okból is. Egyrészt a technológiai nehézségek másrészt pedig azért, mert a piaci igények nem nőnek akkora tempóban. A lényeg inkább az lesz, hogy a lassulás közben szépen felzárkóznak az alternatív technikák, amik nem elsősorban a nagy kapacitással fognak piacot hódítani, hanem például azzal, hogy mozgóalkatrésztől mentesek és ezáltal kevésbé sérülékenyek, nem melegszenek annyira, kevesebbet fogyasztanak stb. stb. Legalábbis ilyesmit gondolok én.

Nem állítottam én, hogy rossz, ha van alternatíva, inkább csak arra gondoltam, hogy nem tudjuk megfelelően kihasználni az előnyeit.

Igazából mégcsak mostanában hasított az agyamba ez a "szörnyűség" :), hogy itten az io ütemezők is bekavarhatnak, úgyhogy még nincs ezügyben eredményem. Nekem is egyenlőre az anticipatory van bekapcsolva.

"Reiser arra kéri a fejlesztőket, hogy ne tegyék a Reiser4-et a VFS-be, hanem használják a Reiser4-et, mint VFS-t. Ne írjanak újabb filerendszereket, hanem írjanak file plugin-okat és diszk formátum plugin-okat a Reiser4-hez."

Szerintem cstamas erre gondolt. Ha ezt is a 2.6.x-ben kezdik el, akkor azért nagy bolydulásra lehet számítani...

Hadd értsem meg, hogy itt mi a probléma:

Nekem valahogy az jött le, hogy a fájlnév, mint azonosító kulcs nem elég hatékony, valahogy tartalom alapján kellene tudni keresni.

Végülis tulajdonképpen tartalom szerint címezhető asszociatív adattárolás kellene, mert az emberi agy is így tárolja és rendezi az emlékeket, tehát ez lenne a legtermészetesebben használható. Ez mondjuk szöveg esetén még működik is, de kép esetén már nehéz. Hogy mondom el a gépnek a kép azt az egy részletét amire emlékszem belőle? Mondjuk az adatbányászat fejlődése ebben segíthet, mert így a képi információ automatizáltan szöveges leírássá lenne alakítható, na de hol van ez még kérem?! És akkor még nem is beszéltem a hangokról, zenékről amire a legtöbb átlagos ember - a zenei szakkifejezések ismerete híján - semmilyen módon nem tud hivatkozni. Eldúdolja a gépnek a dallamot esetleg?! :) Azt hiszem látható, hogy az ideális megoldás messze nem közelíthető meg. Majd, ha gondolattal irányítható gépek lesznek, akkor majd elvileg elképzelhető, hogy magunk elé képezeljük a képet (vagy legalábbis amire emlékezük belőle) és a gép asszociatívan megkeresi az elképzelthez legjobban hasonlítót.

Egyenlőre ennél földhözragadtabb megoldást kell találni. A winfs valami olyasmi (ha jól értelmezem), hogy a fájl jellege (szöveg, hang, kép, videó) alapján csoportosít, amitket tovább lehet bontani finomabb felosztássá (szöveg lehet: levél, újságcikk, kontaktus információk stb.). És minden csoporton belül vannak fontos jellemzők, amik alapján lehet keresni. Például a levél szerzője, címzettje stb alapján. A zenék esetében is van a számnak címe, albuma, előadója, megjelenési éve stb. Ezek az információk már most is benne vannak a legtöbb fileban. (Erre még visszatérek) Tehát akkor az történik, hogy a fájlrendszer számára a fileok már nem csak bájtsorozatok, hanem tudniuk kell valamit a formátumukról, ki kell tudniuk olvasni a tag-eket és fejléceket, hogy a fájlrendszer képes legyen a kiegészítő információ alapján indexelni és keresni. Biztos, hogy ennek a keresési rendszernek az filerendszer szintjén kell történnie? Nem volna jobb inkább valami userspace indexelő erre az egészre? A Linux pl. alapból nem tesz különbséget a fileok között; KDE-ben mégis ha ráböksz valamelyikre, akkor automatikusan a formátumnak megfelelő viewer/editor kerül elő. Ennek is szerintem itt a helye: a desktop környezetbe integráltan. Vagy ha nem, akkor viszont az egész rendszert fundamentálisan fel kell forgatni, nem lehet csak úgy a userspace programok alatt kicserélni a magát a "file fogalmát".

Na most mi van, ha fileokban nincs benne a tag?

Ha nincs benne, akkor dől az egész koncepció, mert a usernek kell egyenként ellátnia a fileokat ezzekkel a kiegészítő az adatokkal, amit szerintem mindenki rühellni fog, mert időigényes; pontosan annyira, mintha rendet kellene tartania fájlnevek és könyvtárak között. A userek ezt nem fogják rendesen csinálni, aminek az lesz a vége, hogy pont olyan nehéz lesz megtalálni valamit, mint most. Rövidzár! Persze lehet ám, (és most hadd jöjjön elő belőlem a pesszimista összeesküvés elmélet mániás) hogy a M$ a jövőt úgy látja, hogy a userek csak ne akarjanak maguk információt előállítani, hanem vegyék a lemezkiadóktól a drága pénzen beszerezhető előretaggelt cuccokat.

( necrolite | 2004. 08. 29., v – 07:48 )

Tehat Herr Reisernek az volna a gondja hogy sajnalja 11 evnyi munkalyat. Ez tiszta sor! De ha a csipkerozsika almabol felriadna akkor eszrevenne hogy pl az SGI XFS-ben (emellett IBM JFS szinten) "talan" fexik szinten min. 11 evnyi munka es talan tobb ember munkaja meg tobb penz. Szerintem orulni kellene hogy ok odaadtak a realtime naplozo filerendszeruket es folyamatosan javitgatjak a linux kernelhez. En azt hasznalom es nekem boven eleg gyors szerveren. Es ha osszeomlik nem akarok a keszitol egy gyunyos levelet kapni hogy ha elkuldom neki a hdd-t majd helyreallitja... (a la Herr Reiser)

Igen. Sok mindenre mondtak azt a szamitastechnikaban, hogy lehetetlen. Lehet, hogy nem ez a klasszikus merevlemez lesz, hanem mas lesz a fizikai megvalositas, de hogy az ember egyre tobb adatot akar majd tarolni az biztos. En csak abbol indulok ki, hogy ha vettem uj HDD-t akkor mindig azt gondoltam, hogy ez aztan sose fog betelni. Nem kellett sok ido, es mar tele is volt. Egyebkent sok TB-ot nem csak egy lemezbol lehet kihozni. Gondolj arra, hogy olcso ATA lemezekbol epitesz tombot. Mar most lehet konnyen TB-os tombot epiteni olcson. Erre is kell valami filerendszer...

hát ez ott fog eldőlni mikor az első pluginok elkészülnek, ha tényleg könnyű fejleszteni/portolni a meglévő fs-eket akkor valószínünek tartom hogy nem lesz nagy gond, nem hiszem ugyanis mikor pl ext3 plugin elkészül az ext3 driver kikerülne a kernelből, tehát inkább azt tudom elképzelni hogy egyideig mind a 2 benn maradna és azt használná az ember amelyiket akarja. kiváncsi lennék amúgy ext3, xfs, jfs maintainerek véleményére - lehet hogy nekiugrom a teljes threadnek ;)

Valami ilyesmit akartam írni én is. Az XFS igen jó, most csináltam ezzel és az Ext3-mal teszteket egy 240 GB-os SATA RAID10 tömbön egy 3Ware vezérlőn, többféle stripemérettel, többféle teszttel (az Ext3-at elég jól lenyomja szinte mindenhol, bár ez most nem tartozik ide).

Ha az SGI-nek ez a filerendszer megfelel irdatlan méretű szuperszámítógépek építéséhez, akkor másnak miért ne lenne jó? Az IBM JFS valószínűleg hasonlóképpen méretezhető, de azt nem ismerem.

Nekem tisztára úgy tűnik, hogy egyre több open source programozó megőrül a marketing hatására - többek között az MS marketingje -, és olyan dolgokat akarnak Linuxon csinálni, amit talán nem kéne (pl. még inkább széjjelb*szni a stabilnak mondott 2.6-os szériát). De itt nem csak Reiserre gondolok, hanem pl. De Icaza is ilyen nekem a Monóval. :I

Azért azt ne feledjük el, hogy az XFS nagyon nagy mennyiségű adatot tart a memóriában hosszú ideig diszkre írás nélkül, így az áramszünetre rendkívül érzékeny. Használatához minimum UPS javasolt (gyakorlatilag meg két oldali betáp, UPS és készenlétben álló aggregátor - de ezek ugye egy normális gépteremben megvannak). Az ext3 ilyen szempontból jóval kevésbé érzékeny.

Ezért aztán üzleti feléhasználásra az XFS tényleg jó, de az otthoni gépem adatait nem bíznám rá.

>Ami meg nem jelenti, hogy 40 TB leveled lesz, azt pedig vegkepp nem, hogy a leveledben a kernelnek kell keresgelnie.

de lesz mp3, ogg meg 10+ audio formatum, 84 fele video formatum, 124 fele szoveg formatum, ugyanennyi archive tipus, es milyen egyszeru lenne ha a filerendszerben ugy lehetne keresni, ahogy Spotlight elorevetiti...

http://www.apple.com/macosx/tiger/spotlighttech.html

>Az e-mail programod pl. nem a kernel resze es megis turhetoen hasznalhato.

meg... bar mar most is sokszor elviselhetetlenul sokat kell varni, pedig csak neha keresek a 2000-tol napjainkig levelezesemben, es csak 2GB-os a mail inboxom (persze ez csak a privat box, nincs benne semmi mas, azok kulon boxban vannak)

De itt nem csak Reiserre gondolok, hanem pl. De Icaza is ilyen nekem a Monóval. :I

Pedig ha nem követő technológiák akarnak maradni örökre, akkor ideje ilyen irányba lépni... ;)

Ez nem marketing, az MS-nél sem a marketingesek adják meg a technikai fejlődés fő vonalát, az ott dolgozó szakértők pedig nagyon jól tudják, hogy milyen irányba kell tovább fejleszteni.

Azert, mert az egesz filerendszer dolog nagyon regen ELVAULT amit ma hasznalunk. Gondoljunk csak arra hogy Tbyte-okkal dobalozunk mar filerendszer meretek teruleten. Ha van egy jo par gigas file aminek pl az ELEJERE be kell szurni egyetlen byte-ot, akkor manapsag erre a megoldas hogy ujra kell irni gyakorlatilag az EGESZ file-t EGYETLEN byte kedveert. Remalom. Pedig lehetne pl beszuro funkcio file irasnal. Es hasonlok. Tovabba: legyen egy konyvtar es a meretere vagyunk kivancsiak (lasd: du parancs pl), de folyamatosan mikozben a konyvtarak tartalma allandoan valtozik es legyen benne sok-sok szintu dir. struktura. Nos, erre jelenleg nincs jo megoldas,pedig a kernel tudhatna erre a valaszt (hisz a kernelen at megy minden vegulis ami userspace programok kezdemenyeznek), tehat lehetne on-line real-time info errol ... Stb. Csak ehhez mind-mind az kell hogy szakitsunk a tobb evtizedes file hagyomanyokkal es fejlesszuk vegre a technikat ... Az is hogy van kulon fs meg adatbazis is csak azert vanb mert anno nem tudtak hatekonyan megoldani a kettot egyutt. Ma mar a ketto sokkal kozelebb van csak meg mindig kiserleti stadiumban meret senki sem "meri" bevezetni ...

( playback | 2004. 08. 29., v – 21:11 )

ugy nez ki a longhornbol kiveszik a winFS-t

( Gabucino | 2004. 08. 29., v – 21:16 )

Mint tudjuk, minden rendszer olyan gyors mint a leglassabb alkotóeleme. Ezért evidens, hogy hiába van akármilyen advanced filerendszer, ha az input már évtizedek óta gyakorlatilag billentyűzetre és egérre korlátozódik.

Futurisztikusan hangozhat, de az igazi megoldás a közvetlen neurális kapcsolat az agy, és a számítógép között, mint ahogyan azt W. Gibson előrevetítette anno.