Re: Transfering large files (was: Unison hangs on copy)
On Tue, Jul 26, 2011 at 03:24:11PM +0200, Claudius Hubig wrote:
> Victor Munoz <vmunoz@macul.ciencias.uchile.cl> wrote:
> >Both replicas are very large, and the few listed changes showed no
> >large files, or so I thought. But it turns out I was wrong, and a 20M
> >file was involved. I deleted the cache file, and reconstructed the
> >mirror, and I finally discovered that unison hangs when this
> >particular large files is involved. There are other large (and larger,
> >4 times larger, for instance) files in the replicas, but they are
> >identical, and unison doesn't complain. Only with this file, which
> >differs.
> >
> >So I tried rsyncinc another file, 23 M in size (with --progress
> >option), and surprise, it stops when 11% transfer is reached. Tried
> >with scp, and same magic number: 11% and it stops.
>
> What happens if you try to copy this file locally or on some other
> device or force reading it with, for example, dd (dd
> if=/path/to/yourfile of=/dev/null). Maybe the storage device on which
> it is located has some bad blocks. You could also try to run scp
> within strace to see where or what hangs.
>
I tried various combinations of this. I tried several different files,
all above 1M, none was fully transfered by rsync or scp :-( Looks like
an issue with keeping the connection alive. Using dd doesn't give
problems. scp within strace shows, at the end, messages like this:
write(6, ")\377K\373)\377X\373#\377\373
\377n\373$\377\206\373\"\377\231\373\36\377\257\373\"\377\323\373"...,
16384) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLOUT}], 1, -1) = ? ERESTART_RESTARTBLOCK (To
be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
By this time the copy is stalled.
Victor
Reply to: