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

[Kenneth D. Merry]

On Wed, Jul 30, 2014 at 23:51:14 +0200, Joerg Wunsch wrote:
> As Alexander Motin wrote:
> 
> > Yes, that was me who removed that second type handling from sastart().
> > The same was done for all other drivers as part of CAM simplification
> > efforts. Probably I missed the fact that sa(4) uses that type for
> > something else.
> 
> Well, a quick glance at the remainder of the driver shows that the
> typemask is just a single bit, so if you remove one of its possible
> values, you should have questioned the entire type field/mask in turn,
> as it became useless then.
> 
> #define	SA_CCB_BUFFER_IO	0x0
> #define	SA_CCB_TYPEMASK		0x1
> #define	SA_POSITION_UPDATED	0x2
> 
> #define	Set_CCB_Type(x, type)				\
> 	x->ccb_h.ccb_pflags &= ~SA_CCB_TYPEMASK;	\
> 	x->ccb_h.ccb_pflags |= type
> 
> 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.

> > So while type may indeed be restored (I have no idea
> > about that aspect of sa(4) driver, neither have hardware to test it)
> 
> Not having the hardware doesn't seem to be a good base for modifying
> the driver in the first place to me.
> 
> Ken, I think that entire CCB_Type stuff can go away then as it is not
> used anymore.  The only side-effect I see is that parts of
> MTIOCERRSTAT are rendered useless now, as the distinction between
> control and IO transfers is gone.

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.)

I've been thinking about implementing an updated version of the
MTIOCERRSTAT ioctl that extends the amount of sense data available.  (Along
with that, it would give the actual sense length, so that the caller knows
how much of the data is valid.)  The other change I've been planning on is
to get mt to actually decode the sense information.  That should be easy once
we have the amount of valid sense data reported in the ioctl.

My current set of patches greatly increase the amount of data available to
applications; most of it is reported via XML.  So this would be going along
with the general theme of giving the user / application more information
and control if they want it.

> 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.
> 
> 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.)

Ken
-- 
Kenneth Merry
ken at FreeBSD.ORG