>In amandad.debug on the client I get:
>...
>amandad: time 2951.811: sending REP packet:
>----
>Amanda 2.4 REP HANDLE 00F-80930508 SEQ 1126652514
>OPTIONS features=fffffeff9ffe7f;
>ar0s1a 0 SIZE 30567356
>ar0s1a 1 SIZE 17959269
>----
>
>amandad: time 2961.819: dgram_recv: timeout after 10 seconds
>amandad: time 2961.819: waiting for ack: timeout, retrying
>...
>In sendsize.debug:
>...
>sendsize[20121]: estimate time for ar0s1a level 0: 320.045
>...
>sendsize[20121]: estimate time for ar0s1a level 1: 2629.405
>sendsize[20113]: time 2951.660: child 20121 terminated normally

It took ~2950 seconds to do the two estimates, based on the various
log messages.  When amandad tried to send back the response/reply (REP)
packet, it never got an acknowledgement (ack) that amdump/planner had
received it.

The default etimeout is 300 seconds.  Amanda multiplies that by the
number of estimates it asks the client to do, so, at best, planner on
the server side gave up after 600 seconds, which is why there wasn't
anyone around to receive the reply and answer it.  If you look at the
amdump.NN file that matches the above you'll probably see planner getting
done well before 2950 seconds.

I'm not sure why this disk is now taking so much longer to do estimates,
but the simplest solution is to just crank up etimeout in your amanda.conf
(or disklist) to compensate.  At least backups will start working again,
and then you can look into possible hardware or file system performance
problems.

>Tommy Eriksen - Chief Technical Officer

JJ