Portál AbcLinuxu, 28. dubna 2024 15:04
Cacheovaci filesystem
24.1.2008 11:58
| Přečteno: 1039×
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:
- grepoval som cez ssh priamo na vzdialenom filesysteme
- 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.
Tiskni
Sdílej:
Komentáře
Vložit další komentář
24.1.2008 14:53
rADOn | skóre: 44
| blog:
bloK
| Praha
python ?
Založit nové vlákno •
Nahoru
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
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.
24.1.2008 14:53
24.1.2008 15:44
25.1.2008 16:15