Sorry, for every NEW run, i would like a set of new logs just for that run just so that i know are from just that run. from my 'novice' eyes, its just to much data to figure out where the previous run completed, and the new one began.
But if i ( ever ) get a complete backup ( after setting it for -6hrs ) i will go back and put it back to 3600. /gat "John R. Jackson" wrote: > > >... 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. ... > > Right. That's the way it's supposed to work, and the way it has worked > for myself and others. > > > > So what do you suggest? >From an admin point of view I would like every disk on my disklist to be backed up. The time that it takes to do it is irrelevant. Time becomes relevant if the avenues of communication is severed between the parent/children ( maxdumps > 1 ) of sendsize, and the communication between client and server becomes severed. How do u know that communication has been lost ? would a 'ping' or keep-alive concept have any use here ? But there are also times when the 'sizer' program may be stuck, spinning to no usefull end. I suppose that in this unusual case/scenario it would be up to the administrator to take the extraordinary action to determine what is causing the 'sizer' failure ( ie is it a bug? is tar backing up /dev/zero ? ) dtimeout represents idle time, why cant etimeout also represent idle time?
