problem s rsyncem na 1.5GB souborech

[Dan Lukes]

Miroslav Lachman wrote:
> Na jednom novem VM (ve VMware u O2) mi ale kazdy den rsync selze u
> prenosu souboru, ktere maji velikost priblizne 1.5GB - jsou to
> databazove dumpy, ktere se tam delaji kazdy den.
> Zalohovani pak spoustim opakovane a po nekolika pokusech to projde.
>
>
> Obvykle to vypise tuhle chybu
>
> rsync daemon
>
> 2016/08/23 23:59:42 [84565] rsync: read error: Connection reset by peer
> (54)

> rsync clinet
>
> 2016/08/23 23:59:42 [94952] rsync: read error: Operation timed out (60)

> Dokazete nekdo z tech chybovych zprav vypozorovat, na ci strane je
> chyba? Prijde mi, ze to svadi jeden na druheho.

Nerekl bych. Sice rsync nepouzivam a tedy moc neznam, ale zda se mi, ze 
klient ztrati schopnost prijimat data od serveru (jednosmerne). Po 
minute ztimeoutuje (ETIMEOUT=60) a spojeni zabortuje. Protoze vypadek 
spojeni je pouze jednosmerny, ten reset na server dojde - no a to je ten 
ECONRESET=54

Takze ted je treba zjistit overit hypotezu (ze jde o jednostrannou 
ztratu spojeni) a nasledne zda k problemu dochazi pri odesilani ze 
serveru, na prenosove trase, nebo pri prijmu na klientovi.

> Navic moc netusim, v cem muze byt problem. Zalohovaci server dela
> stejnym zpusobem zalohy asi z 20 stroju a prenasi i mnohem vetsi
> soubory, nez 1.5GB - bez problemu.

Pak je tedy pravdepodobnejsi, ze problem je na klientovi, ale pozor, 
neni to jiste.

Historka jak nam nesly pres NFS prenaset zcela konkretni soubory 
(zatimco jine prochazely bez problemu) a pricinou byla chyba ve firmware 
switche, ktery fragmentovany NFS paket se zcela konkretnim datovym 
obsahem (a ne jinym) mylne povazoval za (zakazanou) DHCP odpoved a tedy 
ji blokoval tu je uz notoricky znama ...

Dan