Liviu Daia scria la data de 7 Februarie 2006:
> Matei Conovici scria la data de 7 Februarie 2006:
[...]
> > Daca vrei doar sa minimizezi sansele, i/dnotify ca sa vezi daca se
> > umbla pe fs, si astepti un pic sa nu mai apara operatii noi :)
>
> We have a winner! :-) Asta ar putea sa mearga:
>
> (1) Monitorizez directorul cu [di]notify; la fiecare modificare spawn-ez
> un proces care incrementeaza un semafor, asteapta 20 secunde,
> decrementeaza acelasi semafor, apoi iese.
>
> (2) Dintr-un cron job verific semaforul; daca nu e pe zero, iese; daca e
> pe zero face directorul readonly, cheama rsync, apoi face directorul
> read-write.
>
> Probleme ramase:
>
> (a) Inotify nu merge pentru 2.4. Dnotify nu monitorizeaza automat
> directoarele nou create. Solutie posibila: chem dnotify cu optiunea
> "--once" si il repornesc de fiecare data. Problema cu asta: race
> condition.
>
> (b) Mecanismul cu semafoare nu e robust, indiferent ce intgeleg prin
> "semafor". Daca unul din procese moare inainte sa apuce sa
> decrementeze semaforul, sincronizarea nu se mai face niciodata.
Solutia pentru asta ar putea fi sa inlocuiesc semaforul cu un
timestamp (touch /path/to/file) pe care il update-aza fiecare proces
dnotify la inceput, fara sa mai astepte nimic. Asta poate folosi
si ca flag "dirty": procesul cron care face sincronizarea verifica
timestamp-ul; daca exista si e mai vechi de 20 secunde porneste
rsync, altfel iese. Cand rsync a terminat, sterge timestamp-ul (rm
/path/to/file).
> (c) Nu pot face directorul read only fara race conditions. Daca
> directorul este o partitie separata, situatia se imbunatateste
> putin, dar problema ramane.
>
> Pentru semafoare am AFAICT doua posibilitati: SysV IPC (shared
> memory, nu semafoare in sensul ipc(2)), si named pipes. Ambele abordari
> ofera ample oportunitati pentru noi race conditions, si pentru nici una
> comenzile shell standard nu sunt suficiente. De fapt speram intr-o
> solutie mai simpla.
Un fisier timestamp simplifica enorm lucrurile.
Raman deci deschise (a) si (c).
Salutari,
Liviu Daia
--
Dr. Liviu Daia http://www.imar.ro/~daia
_______________________________________________
RLUG mailing list
[email protected]
http://lists.lug.ro/mailman/listinfo/rlug
