Dragos CHIRIAC scria la data de 8 Februarie 2006: > Liviu Daia wrote: [...] > > O solutie rezonabila ar presupune un mecanism de (write) locking > > pentru Samba. Ideal, script-ul de sincronizare ar crea (atomic) un > > lockfile, iar Samba s-ar abtine sa scrie in directorul respectiv > > atat pana cand fisierul respectiv este sters, eventual permitand in > > timpul asta citiri. > > > Adica ce a zis Mircea la inceput, un samba vfs (al naibii de) > custom.
Nu chiar. La inceput vroiam ca Samba sa-mi semnalizeze cand face operatii cu fisiere. Acum vreau ca Samba sa faca un test cand deschide un fisier pentru write in directorul respectiv. Fara sa ma uit in sursele Samba, a doua problema pare mult mai simpla. > Foarte estetic, dar cam proletar. Bleah, nici macar estetic. > Probabil sursele ar fi de ajutor. Desi de la ce face VFS-ul ala pana > la atomizarea scrierii a 5 fisiere mai merge mancata niste pita. Nu, pentru ce vreau eu e suficient. Din script-ul de sincronizare pun lock-ul si apoi testez timestamp-ul. Problema care poate sa apara este ca Samba sa aiba deja un fisier deschis pentru write in momentul in care pun lock-ul, dar atunci timestamp-ul va fi mai recent de 20 secunde (caz in care script-ul trebuie sa lase totul balta si sa iasa), pentru ca primesc notify la deschiderea fisierului. > Imi pare rau, dar eu nu vad cum sa eviti race conditions atata vreme > cat nu ai control dictatorial asupra schedulerului. In general da, un race condition e inevitabil. Pentru ce fac eu insa, cum spuneam, povestea de mai sus pare sa fie suficienta. > Deci solutiile bazate pe FS-uri, snapshoturi, timestampuri si orice > alteva ce implica procese/scripte multiple sunt erorr prone. Ori > samba, ori userii tre sa coopereze, presupunand ca nu exista alte > procese/activitati care scriu in fisierele respective. De acord. Salutari, Liviu Daia -- Dr. Liviu Daia http://www.imar.ro/~daia _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug