On Sunday 28 June 2009 14:55:57 James Harper wrote: > > > I'm getting errors within the first 30G of the backup so it's pretty > > > reproducible within 10 minutes or so. After all that though, the > > error > > > > I'm getting is "The request could not be performed because of an I/O > > > device error."! > > > > I suspect that your drive is configured to run in asynchronous mode, > > and to > > > work with Bacula it must be in syncronous mode -- i.e. the I/O call > > should > > > not return until it has been properly written to the tape. > > After changing the mtops code to not return EIO but rely on the Windows > error handling, I started getting the error a lot sooner. Typically > within the first 5G. It looks like the retry code in block.c (line ~532) > only does a retry on EBUSY or EIO, so my change meant that the retry > code was no longer being called. > > 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. Problems with poorly written drivers are far more common on Win32 than on Linux, because typically it is not Microsoft that writes the drivers ... ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
