>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. ...
Which log files are you talking about? As of 2.4.2p2, every file should have a unique name, most of them based on a datestamp. >But if i ( ever ) get a complete backup ( after setting it for -6hrs ) i >will go back and put it back to 3600. You might consider commenting out some disklist entries and doing a smaller subset to get things going. Then gradually add things back in. Have you looked into why the estimates are taking so long for that client? That would seem to be the root of the issue. >From an admin point of view I would like every disk on my disklist to be >backed up. ... Makes sense :-). >The time that it takes to do it is irrelevant. ... I don't necessarily agree, but moving on ... >Time becomes >relevant if the avenues of communication is severed between the >parent/children ... How do u know that >communication has been lost ? would a 'ping' or keep-alive concept have >any use here ? Possibly. >dtimeout represents idle time, why cant etimeout also represent idle >time? Because during dtimeout there should be data moving all the time. During estimates, there isn't anything going back to the server until everything is done and then there's a single response packet. But I sort of get your point. You'd like ping values and as long as the client is still responding, even though it isn't sending any data (be it the estimates or the actual dump image), just keep waiting for it to get its act together. Does that sum it up? Based on my experience on this list, I think not putting an upper bound on the length of time to wait would be a problem. Clients just plain go silly sometimes, and that would cause the whole run to come to a halt which goes against the "everything should get backed up" principle. You've got to decide when to cut your losses, which is what the timeout values are supposed to do. >/gat John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
