Hans Reiser: a Reiser4-hez több teszter kellene

Con Kolivas fájába már bekerült: http://members.optusnet.com.au/ckolivas/kernel/ [members.optusnet.com.au]

Egyébként a teljesítményproblémákról annyit, hogy egy régi 6.4-es Caviar WD (tehát nem valami gyors) lemezen egy 700-as P3-al CPU limitált!! (Felhívom a figyelmet a reiser4 untar iowait idejere!)

2.6.3-as kernellel van néhány eredményem:

http://home.sch.bme.hu/~xmi/newresults_WD64_summary.html [home.sch.bme.hu]

(az eredmények másodpercben értendők, a pontos parancs megtalálható a raw data alatt)

Ettől függetlenűl azért gyors mint állat. :)

Amúgy egyenlőre semmi hibás működést nem tapasztaltam vele.

(igaz csak /usr/src van rajta)

Szép. Az iowait értékeket honnan kaptad? Vmi megberhelt time, ami magától kiírja, vagy kivontad a real-ből a sys-t és a user-t manuálisan?

Sajnos az utobbi. De nem manualisan. :)

Gondolkodtam rajta, hogy a time-ba belehekkelek meg egy rendszerhivast, ami megadja az iowait idot, de mostanaban ilyesmire nincs idom, helyette jdbc appletet irkalok. Nyilvan korrektabb lenne a kernelbol lekerdezett idot ideirni. Nem tudom, hogy egyaltalan elmeletileg helyes-e az iowait = real - (sys + user), gondolom nem.

Fenetudja, h helyes-e... Lehet, h nem, de valószinűleg jól közelíti. szerintem.

És ha már ennyire benne vagy: kipróbálnád, h mi történik, ha nem sok kis file-lal kell dolgozni, hanem egy processz nagy adagokban [tipikusan 4M] kiír mondjuk 256 megát, aztán syncel? S ugyanezt olvasásra? Vagy ha van még időd/energiád/erődorrásod, akkor a fizikai memória két-háromszorosát (; Köszönöm előre is.

Normalis benchmarkprogram... bonnie++... ezek szerint te meg nem hasznaltad... Egy vicc az a program. Egy nagyon rossz vicc. Valamikor régebben csinaltam bencheket vele (többféle paraméterzéssel is), de elég valószerűtlen dolgokat hozott ki. Majd esetleg előásom annak az eredményeit is, de így kb. ilyenekre emlékszem vissza, hogy a JFS volt a legjobb, a reiser3 meg a legrosszabb a bonnie++ szerint. Azért én a kernelforrás kitarolásának meg a patchelésnek jobban hiszek, mint a bonnie++ által generált random fileoknak.

Elismerem az én benchmarkom is bizonyos mértékig szintetikus, mert senki sem tárol kernelt, meg rendes nagy kernel patcheket tömörítetlen tar fileokban, de ha röptében kellett volna bz2-ből kitömöríteni, akkor gyakorlatilag alig lett volna különbség az fs-ek között. Ennek a tesztnek pont az volt a lényege, hogy kiemeljem a fs-ek teljesítménybeli eltéréseit. Ez alapján ne várja senki, hogy a rendszere mondjuk 2x gyorsabb lesz a reiser4 miatt, mert ez gyakorlatban csak nagyon kiélezett helyzetekben fordul elő.

Igazán jó az lenne, ha volna valami olyan "desktop usage" bench linuxhoz (és *BSD-k hez is) ami például a programok betöltődési idejét és általában a felhasználó akcióira adott válaszidőket mérné. Mert mondjuk pl. egy KDEs (helyettesíts be ide bármit, Mozilla, Openoffice, Gnome) program indításakor be kell tölteni egy rahedli csomó könyvtárat, ott igenis számít a filerendszer teljesítménye, de hogy pontosan mennyit és hogyan (pl a reiser4 nagy cpu használata nem okoz-e több kárt, mint hasznot) azt szerintem most senki sem tudja. Legfeljebb, csak érezni lehet, hogy ez ilyen gyors, pörgős, az meg olyan lomha akadozó, de konkrétan mérni semmit. Egy ilyen eszközzel mellesleg lehetne igazi objektív összehasonlítást végezni még egy csomó egyéb szempontól is (külöböző vm kezelők, cpu ütemezők, io ütemezők, renszerkönyvtárak különböző verziói, Linux vs FreeBSD :) stb. )


Jelenleg nem tudok ilyen eszközről. Ha lenne, az szerintem nagyot dobna a OSS desktop penetráción.

Vannak ilyen eredményeim is, csak formába kéne önteni valahogy az őket (meg aztán nem mindegyik fs-hez van meg).


Így valahogy: time {dd if=/dev/zero of=./testfile bs=4096 count=100000, sync; }

(countra nem emlexem, jo sok, vagy 400MB)

Ja igen, eszembe jutott miért nem raktam be, mert azt másik vinyón (80GB Maxtor 7200rpm) mértem.

Valamikor majd azért felteszem őket.