Paddy Sreenivasan wrote:
On 1/15/06, Jeffrey Borg <jeffreyb AT futureschool.com DOT au> wrote:
Hello,
I am getting errors like the following
encoder /cygdrive/t/Math05/AvidDV/Length lev 0 FAILED [data
timeout]
encoder /cygdrive/t/Math05/AvidDV/BasicMaths1 lev 0 FAILED [data
timeout]
/-- encoder /cygdrive/t/Math05/AvidDV/Length lev 0 FAILED [data timeout]
sendbackup: start [encoder:/cygdrive/t/Math05/AvidDV/Length level 0]
sendbackup: info BACKUP=/usr/bin/tar
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/usr/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
| Total bytes written: 9104711680 (8.5GiB, 807KiB/s)
sendbackup: size 8891320
sendbackup: end
\--------
/-- encoder /cygdrive/t/Math05/AvidDV/BasicMaths1 lev 0 FAILED [data timeout]
sendbackup: start [encoder:/cygdrive/t/Math05/AvidDV/BasicMaths1 level 0]
sendbackup: info BACKUP=/usr/bin/tar
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/usr/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
| Total bytes written: 61298923520 (58GiB, 1.2MiB/s)
sendbackup: size 59862230
sendbackup: end
\--------
now 2 level 0's worked fine 1 level 1 worked fine and 2 level 0 backups on this
machine failed!
I couldn't get amanda 2.4.5pl1 to work on this client under cygwin so I am
using amanda 2.5.0 beta under cygwin on this client only.
What is the value of dtimeout in amanda.conf? Increasing dtimeout
values might help.
IMHO, I doubt that. The dtimeout is the max time that a data connection
may be idle. Unless the dtimeout is configured ridicilously small,
like 1 second or so.
Especially "dump" on unix machines can take some time before
it starts sending bytes, while it is investigating the directory tree.
Maybe gnutar when reading a large sparse file, can take some time too.
And, to be complete, a large non-sparse file filled with very repetitive
data piped to gzip can take some time too, before the tiny compressed
result appears on the output.
But in this case, gnutar did finish already.
It seems like the program did not close the pipe, flushing the last
bytes, to signal the end of the backup processs, and hence after a
while the dtimeout interrupts the backup for that DLE.
Strange. But it does ring me a bell that someone encountered this too.
I cannot find the message anymore though.
Did you build from top of trunk 2.5.0 tree or use 2.5.0b1 images? Top
of trunk 2.5.0 tree
has lots of fixes that might be applicable to this problem.
Always worth investigating, yes indeed.
Is it doing that for any backup from that host now? Can it be
reproduced on a smaller backup? If yes, can you set dtimeout large
enough, so that you have time to follow the sendbackup.*.debug file
and verify with "netstat" that the TCP connections do not get closes
properly?
--
Paul Bijnens, Xplanation Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
|
