Newsgroup: it.comp.os.linux.sys
Titolo: Sincornizzare File systems remoti

Sto cercando di sincronizzare file system remoti (con internet in 
mezzo), in modo che le modifiche fatte da un lato siano riflesse anche 
sull'altro, e questo in entrambi i sensi.
Sto provando unison che in teoria fa quanto promesso, il problema e' che 
quando le direcotry diventano grandi diventa lentissimo a fare le 
scansioni propedeutiche alla sincronizzazione vera e propria, anche 
dandogli le varie opzioni per velocizzare il processo.
Conoscete altri software adatti a questo scopo? Vorrei evitare di usare 
rsync in quanto da quanto leggo e' prevalentemente destinato ad un uno 
unidirezionale.

uno unidirezionale.
"uso", ovviamente

 sull'altro, e questo in entrambi i sensi.
Se tra una sincronizzazione l'altra un file venisse modificato da ambo 
le parti come si dovrebbe comportare il programma?
Oppure vuoi qualcosa che aggiorni i file da ambo le parti in modo 
"realtime", con le latenze di internet?
Alessandro

 dandogli le varie opzioni per velocizzare il processo.
Ma che banda hai? Quanti dati devi sincronizzare?

 le parti come si dovrebbe comportare il programma?
Sovrascrive il piu' vecchio, ma sono cose che dovrebbero accadere molto 
di rado, per come e' gestito il caso specifico.

 Ma che banda hai? Quanti dati devi sincronizzare?
Pochi mega giornalieri per cui credo di farcela tranquillamente durante 
la notte, ma le directory contengono migliaia di file essendosi 
stratificate negli anni.

 di rado, per come e' gestito il caso specifico.
Spiego meglio:
si tratta di un archivio di file di cad, che sono gestiti in gran parte 
come riferimenti esterni: cioe' esiste un file assembly che di massima 
e' un puntatore logico a file singoli.
Finora ho gestito con memorie esterne e dischi usb, ma fra riferimenti 
assoluti e relativi spesso il file assembly si confonde e non trova piu' 
alcuni file a cui punta quando mi sposto da una locazione ad un'altra. 
Allora la cosa ideale sarebbe un processo che sincronizzi il lavoro 
fatto su A il martedi durante la notte fra martedi e mercoledi, in modo 
tale che quando il mercoledi mattina saro' nella locazione B avro' una 
situazione indistinguibile da quella che avevo lasciato in A (ho 
semplificato, le cose sono un po' piu' complesse di cosi', tali da dover 
scartare l'idea di tenere tutto l'archivio su un unico disco esterno).

unidirezionale.
Il problema principale è che rsync conosce solo il concetto di "il file
più nuovo vince", per cui, se tutti e due i lati modificano il medesimo
file, quello dei due che ha "salvato per ultimo" (non che ha aperto per
primo, o fatto piu' modifiche), vede la sua copia replicata; l'altro lo
prende nel ciocco.
Controlla prima (rsync -n) se anche rsync ha lo stesso problema: perché
in quel caso il guaio è altrove e va risolto altrimenti.
In una situazione complessa, ho preferito farmi da me lo script, usando
un primo passo per modificare/segnalare file "impropri" (scritti da una
stazione Macintosh con dei nomi orripilanti, contenenti a volte anche i
diacritici dell'alfabeto Klingon); un secondo passo per individuare tra
N sistemi quali fossero i file modificati in piu' di un sistema, usando
per riconciliare i files un piccolo database MySQL; una volta che tutti
i file erano "al posto giusto", rsync incrociati a squadre, nell'ordine
piu' adatto.
I tempi erano buonini. Rifacendo ora il test a mano:
# time find /srv/www -printf "INSERT INTO firstpass VALUES
(%A@,%C@,'%h/%f');\n" | gzip -9 > zot
real    0m5.856s
user    0m7.320s
sys     0m2.904s
# find /srv/www | wc -l
686764
# ls -la zot
-rw-r--r-- 1 root root 3494955 2010-12-29 16:53 zot
...vengono trasferiti 4 Mb, da ciascuno dei sistemi periferici verso il
sistema centrale (in teoria potrei usare "-*newer" per considerare solo
i file dal precedente sync):
# time find /srv/www -mtime 7 -printf "INSERT INTO firstpass VALUES
(%A@,%C@,'%h/%f');\n" | gzip -9 > zot2
real    0m3.263s
user    0m0.764s
sys     0m2.500s
$ ls -la zot2
-rw-r--r-- 1 root root 4217 2010-12-29 16:58 zot2
zcat zot2 | wc -l
427
...427 file modificati su poco meno di 700 mila, e 5 K di dati soltanto
per stabilirlo, in meno di quattro secondi (**a stazione**... quando ne
hai venti, di server remoti...).
Ho una tabella che mantiene lo stato dopo il sync precedente. Su questa
faccio un INSERT IGNORE basato su filename e timestamp: i record uguali
non vengono inseriti, i record duplicati per filename esistono in due o
piu' copie. Se esistono solo due copie e' un aggiornamento regolare. Se
ne esistono piu' di due, e' un conflitto.
Su 427, diciamo che una decina saranno in conflitto. Lo script non puo'
decidere (NESSUNO puo' farlo automaticamente) come risolverli, e quindi
la grana viene girata per mail agli owner di quei file... poi ogni file
veniva rinominato, in modo che "-exclude '*.sex'" non li veda. Il resto
dei file non sono in conflitto e si possono rsyncare a valanga.
Comunque, una volta che HAI i conflitti, li puoi risolvere anche in più
modi. Che so, ordinando le versioni per timestamp:
	A - originale
	B
	C
	D - piu' recente
...tieni D, e invii per posta B e C ai proprietari (o li rinomini; o li
metti su storage esterno e poi li cancelli).
Questo sistema NON gestisce i delete, cio' richiederebbe l'integrazione
con Samba o simili (o un'ulteriore analisi del DB), per stabilire se la
non-presenza di un file sulla stazione N significhi che il file bisogna
copiarlo sulla stazione N, oppure piuttosto cancellarlo dalle altre.
Un altro sistema che potrebbe valere la pena e' CODA.
 
http://www.coda.cs.cmu.edu/
Comunque, non sono rose e fiori:
 
http://www.coda.cs.cmu.edu/doc/html/coda-howto-4.html#ss4.7
e lo sharing puo' essere un discreto rodimento (MS Word? Anyone?)
Leonardo TMTOWTDI
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

 e' un puntatore logico a file singoli.
La butto lì: un cvs? Qui siamo passati da directory condivise a lavorare 
in locale con subversion (sotto win7, con tortoiseSvn) e funziona tutto 
egregiamente.
Parlo di vari gb di dati; molti di file e molto grossi.
Se non erro la trasmissione dei file è compressa, e l'individuazione 
delle modifiche prende pochi secondi.
Devi solo farti qualche script automatico di aggiornamento (push/pull).
Alessandro

 prende nel ciocco.
Ti ringrazio per la dettagliata descrizione. Il lavoro che hai fatto e' 
molto interessante, ma penso che nel mio caso sia come sparare alle 
mosche con il cannone, inoltre non sarei mai in grado di rifare quanto 
hai realizzato tu.
Comunque stanotte ho fatto una prova con unison ed e' andato tutto bene, 
penso che lo provero' un po' piu' a lungo e poi mi faro risentire qui' 
con un mini report.

con un mini report.
Non scartare l'ipotesi di Alessandro, di usare SVN. Ha client per ogni
piattaforma, e funzioni molto utili per risolvere conflitti, che è una
cosa che succederà e per cui nessun tool automatico può risolvere.
Io, appunto, dopo sei mesi di sbattimenti di testa (e litigi continui)
mi feci lo script che ogni volta infamava i responsabili per email. Fu
l'unico modo :'-(((
Leonardo


 Alessandro
Vedo come muovermi, non ho mai sentito aprlare di questo subversion (di 
mestiere faccio altro! :-) )
Grazie molte per il suggerimento.

 un'altra.
se solo tu usi l'ambaradan, rsync può andar bene perché non ci sono
conflitti
-- 
 I wish we'd come to our senses and see there is no truth


Allora, dopo qualche giorno di prova posso dire che va tutto bene.
Da una parte una macchina Slackware 13.1, dall'altra un Nas QNap TS-210. 
Il software di sincronizzazione e' unison, che lavora su un canale ssh.