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ó.