Cacheovaci filesystem

24.1.2008 11:58 | Přečteno: 1258×

Mozno to podaktori poznate - clovek nieco robi z domu v praci, pripadne na nejakom vzdialenom stroji, z ktoreho ma primountovany filesystem na svoj lokalny stroj, na ktorom edituje zdrojaky, upravuje subory a tak podobne. Vacsinou edituje len par suborov, takze pomala linka mu az tolko zily netrha, ved tych par kB hore dole sa prezije. Pruser vsak nastane, pokial je potrebne nieco v halde suborov najst.

Ja som to doteraz robil dvomi krkolomnymi sposobmi:

1. grepoval som cez ssh priamo na vzdialenom filesysteme
2. rsyncoval zdrojaky medzi lokalnym a vzdialenym strojom pred kazdym buildom

Prvy sposob mi neumoznil vyuzit integrovane vyhladavanie v mojom IDE, druhy zaberal vela casu pred samotnym zapocatim buildovacieho procesu. A tak ma napadlo skusit nieco vygooglit. Nasiel som mcachefs pre FUSE, ale ten je len read-only. Z googlu vypadlo aj par odkazov na kernelovy modul, ktory by mal vediet presne to, co potrebujem a spolupracoval by s NFS, ale v lenny kerneli ho nikde nevidim a podla toho, co som vygoogloval, je to len v -mm strome vo forme patchov a v niekolkych roznych implementaciach userspace utilit. A na to nemam cas ani nervy. A tak prisla na radu tretia moznost:

Napisem si to sam.

Ako backend som si zvolil FUSE a ako jazyk najprv C(++), ale zistil som, ze to nakoniec asi podstatne rychlejsie napisem v pythone ( praca so subormi, adresarovymi cestami, listami, v stl je to proste hnus a qt4-core mi na filesystem neprisla ako vhodna zavislost ).

A tak sa aj stalo. Funguje to nasledovne:

'fcachefs mount_point source_directory cache_directory' pripoji do adresara mount_point 'virtualny' filesystem strukturou zodpovedajuci source_dir, ale s tym, ze akekolvek read() operacie nad obsahom samotnych suborov su uskutocnene nad subormi ulozenymi v lokalnej cache ( cache_dir ). Pri kazdom otvoreni suboru sa najprv porovnaju modifikacne casy medzi source a cache a pripadne sa dany subor pred otvorenim aktualizuje. Zapis sa vykonava paralelne do cache aj do source, aby sa nemusel zbytocne pri dalsom otvoreni prenasat naspat do cache. Vsetky operacie nesuvisiace s obsahom suboru ( readdir, mkdir, chown, ... ) su vykonane nad source_dir, co limituje funkcnost cache na dostupnost suborov v zdrojovom adresari ( takze ak padne linka, mate smolu. Ziadne clusterovanie sa nekona :o) ).

V kazdom pripade to splnilo presne to, co od toho potrebujem, pokial to vyuzije este niekto iny, budem rad.

Zatial je to len v svn na sf.net, casom k tomu spravim readme a nejake tie baliky. Zavislosti su tri - fuse, fuse-python a python. Napriek tomu, ze do toho dost commitujem, sa to snazim udrzovat vo funkcnom stave, ale za nic nerucim. Momentalne tam pridavam logovanie statistik, aby clovek vedel, kolko elektronov v drate usetril, neotestoval som, ako sa to chova k symlinkom a tak dalej...

Ake je resume? Niekedy si clovek napise veci skor sam, ako rozchodi nieco, s cim nema ziadnu skusenost. Celkovo mi to zabralo cca tyzden prace, z toho 4 dni googlovania, ako sa vyhnut programovaniu vlastnej veci a zvysok casu som premrhal kvoli extremne skupej dokumentacii od python-fuse.        

Komentáře

[rADOn]

při vší úctě, ani k filesystemu v userspace nemám moc velkou důvěru. filesystem v pythonu... no poteš koště

já tohle řeším tak že si to namountím přes sshfs do lokálu a na to poštvu ide a shell zůstane přes ssh (svn nemá sshfs rádo a cvs ho přímo nesnáší). problém je ze ssh neudrží moč ani spojení ale to naštěstí můj editor přežije.

[msk]

To ano, takto som to riesil doteraz. Ale vobec to neriesi opakovane citanie z tych istych suborov - vsetko sa to znovu a znovu taha po linke.

[msk]

při vší úctě, ani k filesystemu v userspace nemám moc velkou důvěru... já tohle řeším tak že si to namountím přes sshfs ...

BTW, sshfs je filesystem v userspace.

[rADOn]

Taky to podle toho vypada - kdyz mi umre proces ssh tak lehne i sshfs apod. Ale nevykladejte si to tak ze mam neco proti FUSE, verim ze na spousty veci je to genialni vec. Jen kdyz ho vidim tak zbystrim abych naaahodou nenarazil na nekterej z tech pripadu kde az tak genialni neni :-/

[msk]

kdyz mi umre proces ssh tak lehne i sshfs

To mi ale pripada dost logicke. Co ine by mal urobit?

[Josef Kufner]

Zkusit se znovu připojit?

[msk]

A co s otvorenymi subormi?

[Josef Kufner]

Totez co udela kazdy slusny filesystem... i/o error.

[Petr Masopust]

Ja jsem si jednou jen tak z legrace udelal taky FS nad fuse a to dokonce v jave :)

Radsi jsem ho ale nikde nepublikoval - byla to vazne jenom hracka s mizernym vykonem. Ale na druhou stranu pri vhodnem nastaveni podporoval clustering.

[Filip Jirsák]

A nechtěl byste ho někde přeci jen publikovat? Aspoň pro inspiraci jak komunikovat mezi Javou a FUSE…

[Petr Masopust]

Pouzil jsem http://sourceforge.net/projects/fuse-j - zbytek je uz o implementaci.

[Filip Jirsák]

Díky, to jsem neznal. Přidávám do záložek

[Josef Kufner]

Náhodou, FUSE je supr věc. Jsem si takle napsal jednoduchý skoro-filesystem, který se mountne do /media a podle fstab a /dev tam pak vytváří mountpointy. Prostě a jednoduše koukne do fstab, a pokud existuje zařízení, tak existuje i mount point. Jednoduché a užitečné