Direct I/O torrent kliens

Linux-kezdő

Sziasztok!

Keresek olyan linuxos torrent klienst, ami direkt hozzáférést használ az olvasott fájlok elérésére, az OS page cache megkerülésével. Külön öröm lenne, ha ezen túl azért ő saját magának fenntartana valamilyen szabályozható méretű gyorsítótárat.
Az ok: a gépemben lévő 4GB memória ellenére - főleg mostanában, hogy sokat kell virtuális gépeket használnom - olyan cache "vergődést" (hehe, ez de egy hülye szó, de magyarul így tanítják) tapasztalok, hogy a felhasználói élmény a használhatatlanság határát súrolja.

Tudom, hogy a meglévő kliensem forrásának is nekieshetnék és átírhatnám, de momentán ehhez se kedvem, se időm, illetve örülnék, ha valami tesztelt, jól működő megoldást találnék.

Gugli eddig nem segített.

Köszi!

( Zs | 2012. 03. 25., v – 21:16 )

Mit értesz direct I/O alatt? Ha arra gondolsz, hogy közvetlenül lenyúl a winyóra, akkor szerintem nem igazán fogsz ilyet találni. A winyó direkt irkálása ugyanis felvet pár problémát:
- ha a kötet csatolva van, akkor a kernel nem fog tudni arról, hogy "alányúltak", így a cache és a tartalom el fog térni. Ebből irgalmatlan problémák lesznek...
- a torrent kliensbe implementálni kell egy komplett file-system kezelő modult, mert a sedeléshez tudni kell olvasni a file-okat, de a letöltéshez nyilván írni is kell tudni beléjük. Természetesen könyvtár kezeléssel együtt, hiszen ha olyan a torrent file, akkor könyvtár struktúra is van benne.
Ilyen paraméterek mellett nem igazán hiszem, hogy torrent kliens irányában lesz ilyen megoldás - akkor viszont marad az, hogy kernel hívások. Az meg mindenképpen cachel. Ha nagyon ebbe az irányba akrsz menni, akkor FUSE: csatolsz egy könyvtárat FUSE-n keresztül, oda torrentezel - a FUSE részt meg megírod úgy, hogy ne legyen cache. ;-)

Nem ennyire mélyen szeretnék lenyúlni a lemezre, csak a page cache-t lenne jó kikerülni. (lásd open hívás O_DIRECT, illetve volt valami ilyen fopen-hez is)
Kb. ennyit kellene amúgy belehegsztenem a most használt transmission-be, csak így a félév küzepén nem igazán van ilyen irányban elüthető szabadidőm.

Az a baj, ez nem oldja meg a gondot, mert:
Vagy adok egy jó nagy diszket a virtuális gépnek, és megkérem a vmm-et hogy ugyan ne használd már a page cache-t. De ez így baromirarugalmatlan, mind a hostról elpazarolt hely, mind bővíthetőség szempontjából.
Vagy a megosztott fájlrendszer megoldásokat próbálom használni -> megint bekerülnek a fájlok a cache-be.

( Finder | 2012. 03. 25., v – 21:57 )

Értem, hogy mit akarsz, de azt nem értem, hogy miért.
Pontosan milyen problémát tapasztalsz?

Elindítok 1-2 virtuális gépet. Ezek együtt lefoglalnak ~2 GB memóriát.Valamint fut még ez-az a hoston is.
Az egyik baj, hogy előbb-utóbb a rendszer a 0-ra állított swappiness mellett is vad swappelésbe kezd, miközben van még ~ 600-700 MB szabad fizikai memória. Nem tudom ugyan, hogy pontosan hogyan máködik a Linux memóriamenedzsmentje, de az biztos, hogy hasonló memórikihasználtság mellett, ha nincs állandó nagy mennyiségű IO, békénhagyja a swapet.
A másik, hogy nagyon hamar kikerülnek a cacheből az egyébként szükséges dolgok, mint fájlkezelő, xmms (ugye lirc hívogatja a binárist), openoffice. Mindenre ezer évet kell várni, mire elindul, stb...
Szerk.: mindez persze teljesen feleslegesen, mert a seedben tartott ~100GB _tényleg jogtiszta_ anyagból elég ritkán kell ugyanaz, a 4GB fizikai memóriába meg ugye messze nem fér be...