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]