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
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
