On Monday 29 June 2009 09:14:32 James Harper wrote: > > > I put some retry code in mtops with a heap of debugging and sure > > enough, > > > > the WriteFile call fails sometimes, but then works the 2nd or 3rd > > > attempt. > > > > > > It seems strange to me that 'lets just try that again' is an > > acceptable > > > > response to an I/O error... but maybe Linux has that problem too? > > Unless > > > > the retry loop in block.c was put there for Windows too? > > > > No, the retry loop in block.c was put there to handle very precise > > conditions. > > > In general, it is not just OK on any old I/O error to try again. On > > Unix > > > systems there is a well defined sequence of operations that are > > permitted ... > > > > I'm a little baffled... > > > > Yes, well tape I/O on Unix is *very* tricky, so whatever you do, make > > sure > > > that the changes in core code only apply to Win32 systems, and even > > there, > > > you may find problems. > > The changes I've made are certainly not production ready, and I'll limit > them to mtops.cpp - the retry loop can go in there if it is indeed > required. > > I have just completed a 200G backup, and the retry loop was activated as > follows: > . Lots of "worked on 2nd attempt" messages > . Lots of "worked on 3rd attempt" messages but not quite as many as > above > . 1 of "worked on the 5th attempt" which would have been enough to fail > the existing "retry 3 times" code in block.c > > I'll investigate doing some deeper error code retrieval - maybe even try > and get the sense data although I don't know if that's possible. There > may be some condition we can test for to know that it's ok to retry vs > knowing when it's a hard error.
Yes, well, you should never retry if it is a hard error. The Bacula code in block.c retries only if it gets an EBUSY status. In fact, Bacula should never get an EBUSY status, but there are some stupid (Unix/Linux) OSes out there, so we resolved the problems with the retry loop. > > Why does everything have to be so hard!!! Because it is programmed by humans, and sometimes they don't really understand all the consequences of everything ... > > > Problems with poorly written drivers are far more > > common on Win32 than on Linux, because typically it is not Microsoft > > that > > > writes the drivers ... > > And yet with all the WHQL testing that you have to do (and it's painful) > it's _supposed_ to be the other way around :) > Well, that is the inevitable result when the source is not available. ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
