> > 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.
>
How sure are you about that?
do {
...
stat = dev->write(block->buf, (size_t)wlen);
} while (stat == -1 && (errno == EBUSY || errno == EIO) && retry++ < 3);
It definitely tests for EIO there. Curiously though, the '...' bit that
I omitted for clarity only does a sleep and clrerror() on EBUSY, not on
EIO.
Without the test for EIO, my backups would never complete successfully
under Windows. With 3 retries it is enough to get them working most of
the time. But if there is Windows specific retry code required it should
probably go in mtops.cpp and the EIO test there should be removed.
I added some code to mtops.cpp to get the scsi error sense data and it
always comes up clean, but I'm not yet sure if that's because it was
cleared by Windows, or if the error is not scsi related.
I also tried adding a call to GetTapeStatus before every write to see if
the device is ready for io, but it always says it is.
I'm still wondering if some other part of Windows is poking at the drive
every so often and interfering with us, even though we have the device
opened exclusively. Normally I'd use procmon from sysinternals but it
doesn't seem to like me under 64 bit - it never shows any tape drive
access.
>
> > 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.
>
Having done application programming and kernel programming on both
Windows and Linux, they couldn't be more dissimilar. Linux is barely
documented but as long as you can read the code you'll probably get
where you are going. Also, there is no such thing as undocumented calls.
Windows on the other hand is actually really well documented, provided
the only things you want to do are things that the designers thought of.
And you must never ever use an undocumented call or rely on undocumented
behaviour, or bad things might happen. *sigh*.
James
------------------------------------------------------------------------------
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
