Thanks for your answers. Actually I've restarted amdump yesterday with an
increased estimate timeout (I've set it to 30000 (~8 hours)) and it seems
that estimation was OK. However it really takes forever to backup this
partition as amdump is still running (now writing to the tape). So the
next question is how I could make it finish (estimation + tape writing)
within 8 hours?? Would ufsdump solve the problem or should I somehow split
the directories (how?)

Here is the output from amstatus:

amanda@rozi$ amstatus cab
Using /var/amanda/cab/amdump from Tue Nov 11 21:15:23 CET 2003

lena2.cab.u-szeged.hu:/etc              1      550k finished (13:18:18)
lena2.cab.u-szeged.hu:/root/ldap_backup 1     1380k finished (13:18:33)
rozi.cab.u-szeged.hu:/etc               0     3650k finished (13:18:24)
rozi.cab.u-szeged.hu:/home              0 52341980k dumping to tape
(13:18:33)

SUMMARY          part      real  estimated
                           size       size
partition       :   4
estimated       :   4             52347560k
flush           :   0         0k
failed          :   0                    0k           (  0.00%)
wait for dumping:   0                    0k           (  0.00%)
dumping to tape :   1             52341980k           ( 99.99%)
dumping         :   0         0k         0k (  0.00%) (  0.00%)
dumped          :   4  52347560k  52347560k (100.00%) (100.00%)
wait for writing:   0         0k         0k (  0.00%) (  0.00%)
wait to flush   :   0         0k         0k (100.00%) (  0.00%)
writing to tape :   0         0k         0k (  0.00%) (  0.00%)
failed to tape  :   0         0k         0k (  0.00%) (  0.00%)
taped           :   3      5580k      5580k (100.00%) (  0.01%)
3 dumpers idle  : not-idle
taper writing, tapeq: 0
network free kps:    100970
holding space   :  18864378k (100.00%)
 dumper0 busy   :  0:00:05  ( 29.94%)
 dumper1 busy   :  0:00:00  (  3.89%)
   taper busy   :  0:00:11  ( 59.59%)
 0 dumpers busy :  0:00:13  ( 68.96%)          start-wait:  0:00:09  (
72.29%)
                                             no-diskspace:  0:00:03  (
27.71%)
 1 dumper busy  :  0:00:04  ( 26.37%)          start-wait:  0:00:04  (
91.92%)
 2 dumpers busy :  0:00:00  (  4.65%)
amanda@rozi$

__________________________________________________________________

http://www.inf.u-szeged.hu/~kato/  -- research in computer vision
http://www.cameradigita.com/       -- photography (online gallery)
__________________________________________________________________

On Wed, 12 Nov 2003, Stefan G. Weichinger wrote:

> Hi, Zoltan Kato,
>
> on Dienstag, 11. November 2003 at 20:50 you wrote to amanda-users:
>
> ZK> Looks like the estimate has timed out after a 1/2 hour. I do not know why
> ZK> estimation takes so long. What is more interesting: after amdump has
> ZK> finished there is still a gtar process running.
>
> As Jay and Frank already have recommended, I think increasing the
> etimeout value is the way to go.
>
> According to your posting you have 300 seconds for that right now ...
> thatŽs 5 minutes. This is the default value and seems too low for your
> situation. You have loads of files on that partition, so tar has lots
> of work to do, as your former posting of the output of top shows.
>
> The sendsize.debug files in your /tmp/amanda-directory (or whereever
> your amanda-installation puts its logfiles ....) tell you about the
> commands Amanda uses for estimating.
>
> You can find those commands by looking for lines containing something
> like
>
> > getting size via gnutar for /home level 0
>
> Some lines later there follows something like
>
> >  argument list: /bin/tar ....
>
> Run that command manually, maybe even using the time-command:
>
> # time tar ...
>
> This will run for a while, giving back the time it took. Set your
> etimeout somewhat higher and try a run again.
>
> ---
>
> Otherwise set it up to something like 3600 (one hour) and try that.
>
> ---
>
> Another way would be to split the /home-directory into some smaller
> disklist entries.
>
> But more on that later if necessary.
>
> --
> best regards,
> Stefan
>
> Stefan G. Weichinger
> mailto:monitor AT oops.co DOT at
>
>
>