Date: Wed, 30 Jul 2014 21:57:56 -0600 From: "Kenneth D. Merry" <ken@FreeBSD.ORG> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, Alexander Motin <mav@FreeBSD.org>, freebsd-scsi@freebsd.org Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds Message-ID: <20140731035756.GA91452@nargothrond.kdm.org> In-Reply-To: <20140730215113.GA3564@uriah.heep.sax.de> References: <20140729204354.GA78616@nargothrond.kdm.org> <20140729224414.E2AAE276@uriah.heep.sax.de> <20140730035230.GA81800@nargothrond.kdm.org> <20140730060330.GA3272@uriah.heep.sax.de> <20140730153229.GA86368@nargothrond.kdm.org> <20140730191915.9B944267B@uriah.heep.sax.de> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de> <53D95F61.4080701@FreeBSD.org> <20140730215113.GA3564@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140731035756.GA91452>