A Lindows.com támogatja a Reiser4 fejlesztését

Fájlrendszer, NAS, storage

A Lindows.com tegnap bejelentette, hogy hivatalosan is támogatja a Namesys következő generációs ReiserFS filerendszerét, a Reiser4-et. Ez nem meglepő hiszen Michael Robertson a Lindows.com CEO-ja korábban annak az MP3.com-nak volt a vezetője, aki a fő szponzora volt a ReiserFS fejlesztéseinek.

A Lindows.com bejelentette, hogy 2004 elején beépíti a Reiser4-et a LindowsOS operációs rendszerébe. A LindowsOS jelenleg a ReiserFS v3-at használja alapértelmezett filerendszerként. Nem ők az egyetlenek, akik a ReiserFS-t használják. Mellettük a SuSE és a Gentoo is alapértelmezett fs-ként használja a Reiser v3-at.

Mi is a Reiser4?A Reiser4 egy teljesen újraírt verziója a korábbi ReiserFS-nek. A készítők szerint számos olyan fejlett technológiát alkalmaztak a megalkotásakor, amely megakadályozza a filerendszer sérülését, lehetővé teszi a fileok kisebb helyen való tárolását, és emellett kiváló sebességet ad. A Lindows.com sajtóbejelentése szerint jelenleg a ReiserFS a leggyorsabb filerendszer, de a Reiser4 még ennél is 2-5-ször gyorsabb lesz (néhány benchmark itt). Ez köszönhető azoknak az új algoritmusokak, amelyet a Reiser4-ben alkalmaznak. A Reiser4 az adatbázisaiban az ún. ``táncoló fák'' (dancing trees) algoritmust alkalmazza a ``kiegyensúlyozott fa'' (balanced tree) algoritmus helyett. A fejlesztők szerint ez emeli sebességben a Reiser4-et a többi filerendszer fölé. A Reiser4 érdekessége, hogy van magyar vonatkozása is. Hans Reiser - a ReiserFS atyja - nem olyan régen járt Budapesten, hogy egy magyar szakemberrel vitassák meg a Reiser4 algoritmusait. A szakember Földiák Péter, akivel Reiser a filerendszerek szemantikájáról beszélgetett.

Lassan 2 éve csak ReiserFS-t használok a munkaállomásaimon és a mobil gépeimen, így érthető, hogy érdeklődve várom a Reiser4 megjelenését (augusztusi Reiser4 tesztjeim). A Reiser4 honlapja szerint a Reiser4 tesztelése a végső stádiumba érkezett, és hamarosan megjelenik. Kiváncsian várom!

A Lindows.com sajtóbejelentése a Reiser4 támogatásáról itt.

( XMI | 2004. 01. 01., cs – 20:13 )

Hát nem tudom, hogy honnan veszik ezt a 2-5 ször gyorsabb lesz dolgot (bizonyára a *lesz*-en van a hangsúly :) ). Én mostanában teszteltem, novemberben, és elég vegyesek voltak az eredmények: egyes tesztekben *kicsit* jobb, másokban rosszabb a reiser3-nál, átlagban azt mondanám, hogy sebességben nagyjából egyformák. (Én a teszteket kézzel végzem, mert érdekes módon a bonnie++ erősen lehúzza a reiser mindkét változatát, a tényleges tesztek (time tar -xf linux-2.6.0-test11.tar, time find, time du, time rm -r, stb.) szerint viszont most tényleg a két reiser a leggyorsabb, és én ezeknek valahogy jobban hiszek.) Amit viszont észrevettem, hogy a reiser4 kb. 2x annyi cpu időt emészt fel, mint a reiser3 ugyanabban a tesztben. (És, teszem hozzá, idáig is a reiser3 használta a legtöbb cpu időt a linux alatt támogatott filerendszerek közül, ezt most sikerült megdulpázniuk :/ ) Egyszóval nem 486-ra való, de lehet, hogy még a 700-as P3-amon sem tudta teljesen kifutni magát.

Szerintem inkább ezt kéne kihangsúlyozni, hogy "lehetővé teszi a fileok kisebb helyen való tárolását". Egészen pontosan: a _kis_ fájlok hatékony tárolását teszi lehetővé, gyakorlatilag nem pazarol el helyet a blokkméretnél kisebb fájlok esetén sem, valahogyan össze tudja vonni őket egy blokkba. Ezt tudtommal semilyen más fs nem tudja. És eközben sem veszít a sebeségből.(Az más kérdés, hogy ettől mennyire fragmentálódik, erre még nem sikerült jó tesztet kitalálnom. Esetleg kernel patcheléssel lehetne...)

du linux-2.6.0-test11

211992 Ext2

206391 ReiserFS

176066 Reiser4

A reiser4nél a kitarolt kernel forrás alig foglal el több helyet, mint az eredeti tar. Gondolkodom is rajta, hogy az /usr/src -met átrakom reiser4 alá. Azért úgysem kár, ha eseteg elveszne reprodukálható.

>Én mostanában teszteltem, novemberben, és elég vegyesek voltak az eredmények: egyes tesztekben *kicsit* jobb, másokban rosszabb a reiser3-nál, átlagban azt mondanám, hogy sebességben nagyjából egyformák. (Én a teszteket kézzel végzem, mert érdekes módon a bonnie++ erősen lehúzza a reiser mindkét változatát, a tényleges tesztek (time tar -xf linux-2.6.0-test11.tar, time find, time du, time rm -r, stb.) szerint viszont most tényleg a két reiser a leggyorsabb, és én ezeknek valahogy jobban hiszek.) Amit viszont észrevettem, hogy a reiser4 kb. 2x annyi cpu időt emészt fel

En ugyanezeket mertem, ugyanezeket tapasztaltam. Ezert varom a kiadast, hogy lemerhessem ujra. Nekem Hans Reiser azt mondta, hogy rosszul mertem,azert lettek ilyenek az eredmenyek.

( Ysolt | 2004. 01. 02., p – 22:00 )

Hali!

En azert egyenlore arra lennek kivancsi, hogy mikor lesznek mar a rendes vanilia kernelben a reiserfssel kapcsolatos quotas dolgok. Mert ugye abban egyetertunk, hogyha szervert epitunk akkor a quotara azert sokszor sugseg lehet.

A 2.4-es kernelnel me'g ugy tudom az volt a helyzet, hogy azert nem volt reiserfs quota benne, mert az mar a 3as verzioju quotat hasznalna, amely 32 biten tarolja az adatokat, es hat a 2.4es faban meg a regi quota kod volt. Amikor pedig kijott a 2.6 akkor gondodoltam, ha mar benne van a kernelben az uj quota kod akkor jajj de szepen fog menni a reiserfs is. De sajna a gyors kiprobalas alkalmaval kiderult, hogy a mountnal nem igazan akarja bevenni az usrquota opciot:(

Ti mit tudtok errol, lesz valamikor valami valtozas ebben, vagy mindig is a RedHat vagy a Suse fejlesztesu patchel lehet majd ezt az opciot hasznalni?

Egyebkent ezt felreteve nagyonis meg vagyok elegedve a reiserfssel.Mostmar joforman mindenhol azt hasznalom,es szepen mennek a masinak:)

Ysolt

Ui.: Ujra elolvasva az irasomat arra gondoltam, hogy esetleg a binutils csomag lehet tul regi a woodyban, hogy kopkodes nelkul bevegye az usrquota opciot patch nelkul?