From: Arno L. <al...@it...> - 2006-01-04 21:52:02
|
hi, On 1/4/2006 9:42 PM, Kern Sibbald wrote: > On Wednesday 04 January 2006 21:15, Arno Lehmann wrote: >>On 1/4/2006 8:44 PM, Kern Sibbald wrote: ... > Thanks. Got it. > ... > Hmmm. Unfortunately the "trick" I mentioned is not true. I was looking at > your output more in detail when I realized that the locking is one level down > from where I thought it was, which means that all the jobs are trying to run > through the same algorithm at the same time. They are locked from any direct > conflict, but after a bit of thought I think it would be better for a single > job to try all possibilities before letting another job try -- if nothing > else, that will reduce the complexity when trying to figure out what went > wrong. Well, "reducing complexity" almost always is the right thing to do :-) > After looking over your full output in detail, I will probably release version > 1.38.3 tomorrow because it seems to be better than any of the previous > versions, then I'm going to move the locking code up one level of subroutine > to the main loop and add a bit more debug code that could be helpful in > analyzing your problem. Good, then I think I can go on testing that. Tomorrow... Thursday. New version starts running on Friday or Saturday, that gives me at least two days of simple operation to find configuration issues or other bugs before my stressing set up starts. Sounds good. > Assuming looking at your full output doesn't give me the info needed to > resolve the problem, once I test the new locking code and the new debug > output (don't expect any problems) I'll make it available so we can get to > the bottom of this problem ... I'd really really like to get this fixed... after all, there should be more, new, exiting bugs to hunt ;-) (And I guess you'd like to get the known bugs fixed so you can implement new... no! features!!) Arno -- IT-Service Lehmann al...@it... Arno Lehmann http://www.its-lehmann.de |