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
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
