Then my current impression is that the feature does not work - exactly
as stated. There are a few file systems on one 'errant' system, where
one filesystem has taken over 224 minuts( wall time ) to complete just
the estimate. I had changed the time to be some 3600 ( an hour ) which,
if one beleives the man page, would leave some 8hours ( wall time ) for
all 8 partitions to complete. I think the log had 2 timeout errors of
some 3800. The longest, and the next to longest partition did not
complete :-{
I dont think that anyone wants to know who the 'planner' is, or
'sendsize' or even their relationship at a user, or administrative
level. But i suspect that one has to give the 'highest' possible
estimate on a per partition basis.
Its not too rational for the observer program 'planner?' to multiply the
estimate if u can have multiple ( or even a single ) 'sendsize's running
on the client machine ( now set at 8 * 6hrs ) Its just too long to wait
for some failed communication! ( it also ruins the concept of a daily
backup )
"John R. Jackson" wrote:
>
> >etimeout specifies that amount of time amdump will wait to hear back after
> >sending a sendsize request to a particular host. At least, I think it's
> >per-host.
>
> This is covered in the man page:
>
> Default: 300 seconds. Amount of time per disk on a
> given client that the planner step of amdump will wait
> to get the dump size estimates. For instance, with the
> default of 300 seconds and four disks on client A,
> planner will wait up to 20 minutes for that machine. A
> negative value will be interpreted as a total amount of
> time, instead of a per-disk value.
>
> Note that, when positive, it is per disk. When negative, it is per
> host (and the man page needs a minor tweak to make that point).
>
> >Joshua Baker-LePain
>
> John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
