RSync hangs up on file transfer

Andre Alexander Bell andre.bell at gmx.de
Thu Oct 9 04:37:27 EST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 06 October 2003 20:48, jw schultz wrote:
> On Mon, Oct 06, 2003 at 08:20:55PM +0200, Andre Alexander Bell wrote:
> > or even -vvv did allways end up with rsync consuming no more cpu time and
> > the following last output lines (or quite similiar):
> >
> > <--output begins-->
> > match at 1241645 last_match=1240991 j=374 len=700 n=654
> > match at 1242345 last_match=1242345 j=375 len=700 n=0
> > match at 1243965 last_match=1243045 j=573 len=700 n=920
> > match at 1244665 last_match=1244665 j=1 len=700 n=0
> > match at 1246665 last_match=1245365 j=1437 len=700 n=1300
> > match at 1247400 last_match=1247365 j=1782 len=404 n=35
> >      1247804 100%  440.23kB/s    0:00:02
> > done hash search
> > sending file_sum
> > got file_sum
> > renaming .C8760-02_FEU_0378_0000_063x_MASK.tif.vsuS6T to
> > fisher/C8760-02_FEU_0378_0000_063x_MASK.tif
> > set modtime of fisher/C8760-02_FEU_0378_0000_063x_MASK.tif to
> > (1065079671) Thu Oct  2 09:27:51 2003
> > redoing fisher/C8760-02_FEU_0378_0000_063x_MASK.tif(1850)
> > <--output ends-->
>
> How big are these files that it reports "redoing ..."?

They are allways of the same size: 1247804Bytes=1.2MB

> Unless they are quite large i would suspect one of your
> systems has some data corruption problems.  There are three
> ways of getting that error.  One is for there to be hash
> colisions on the data which is statistically rare enough
> that it shouldn't happen exepct on multi-hundred-megabyte

These files are allways images, uncompressed and in tif format.

> files.  The second is for the destination file to change
> between the time checksums are generated and the time it is

The destination is not open to any access, wether directly nor through some
fileserving. The source is served meanwhile by a samba server. Stopping this
service during the rsync process on the sending side does not prevent rsync
from hanging up.

> updated.  The third is for there to be corruption such as
> defective hardware or the destination being on nfs.

These harddisks are 6 month old 200MB ide harddisc drives. So they are quite
new. Nevertheless, since this seems to be the last option to check I'll go
and get some new harddiscs to check for this...

- --
Andre Alexander Bell <andre.bell at gmx.de>
PGP-Public-Key: http://www.andre-bell.de/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/hFlnnuHMhboRh6QRAujOAKCBD0mFNlqqu9v4t/HOZRu5kyHEmwCeJjuD
zx3Idil6Ty/6rfovyRO2tNQ=
=t9Mv
-----END PGP SIGNATURE-----




More information about the rsync mailing list