Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds

[Joerg Wunsch]

As Kenneth D. Merry wrote:

> > SA_CCB_BUFFER_WAITING was indeed not tested anywhere else, but there
> > are decisions based on SA_CCB_BUFFER_IO (which used to be the opposite
> > of SA_CCB_BUFFER_WAITING).  These decisions now became random
> > decisions. :-(
> 
> Ahh, that explains it.

That's also what I thought then ... in particular, it explains why I
have seen one situation where the status has been reported correctly.

> I think it would be good to keep the ability to report to the application
> or the user what happened with control and data commands, especially since
> you may wind up having errors on both types of commands in some cases. 
> (e.g. end of media notification on a write, and then perhaps an issue in
> writing the filemarks.)

OK, then it needs some more work.

> > Unfortunately, the new Bugzilla doesn't seem to accept me (I tried
> > Peter Wemm's description about kinit / kpasswd), so I cannot open
> > a bug report for it.

Meanwhile Eitan Adler helped me a bit, so the bug report is at:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192285

That way, it has been officially recorded, so we can take the time
needed for a real fix.

> > Attached is a suggested patch.  So far, I only compile-tested it.
> 
> As I said, I think it would be better to keep the ability to report both
> control and I/O errors.  If I have time tomorrow I'll try to come up with
> something.  (Or you can if you have the time.)

There's no longer any hurry on it now.  My patch^H^H^H^H^Hhack works,
Bacula could successfully write to the tape automatically for the
first time.  I'll try looking into an improved version, but I wouldn't
want to do too radical changes in order to not cause too much
potential for conflict in your other pending patches.
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)