do we have MTIOCLRERR on ioctl?

[Dan Langille]

Anyone any any ideas about this issue?

------- Forwarded message follows -------
Subject:        	Re: [Bacula-users] Too many errors trying to mount
From:           	Kern Sibbald <kern at sibbald.com>
To:             	Dan Langille <dan at langille.org>
Copies to:      	bacula-users <bacula-users at lists.sourceforge.net>
Organization:   	
Date sent:      	12 May 2003 21:38:43 +0200

Hello Dan,

No, I don't mind you forwarding my email. You can
always do so.

Best regards,

Kern

PS: Just to amplify a bit: When Bacula gets an EOM,
it immediately writes two EOF marks. One would be
sufficient, but this way I am sure that the tape
is terminated for ALL drives.  It then does
two backspace files followed by a backspace
record, if that succeeds, it re-reads the last
record and compares the CRC and block number with
what it wrote and reports success or failure. 

On FreeBSD (at least your case), it was the backspace
record that failed as is the case on a certain number
of tape drives. However, what was unusual was that
it "froze" the tape. Bacula then does an ioctl()
MTIOCLRERR on all systems that support it -- hoping
to clear the error condition.  



On Mon, 2003-05-12 at 19:39, Dan Langille wrote:
> Do you mind if I forward this message to the freebsd-scsi list in
> case someone can suggest something?
> 
> On 12 May 2003 at 19:32, Kern Sibbald wrote:
> 
> > Hello Dan,
> > 
> > Thanks for researching this. I also looked for MTIOCLRERR,
> > but it doesn't seem to exist on FreeBSD.
> > 
> > I looked over the off list email you sent, but it
> > doesn't help much since the problem is not the handling
> > at the soft EOM, but rather what happens when I 
> > try to backup and check the last record. That works
> > fine on Linux and Solaris, but not on FreeBSD, so
> > the solution is to turn off Backward Space Record
> > on FreeBSD.  
> > 
> > Though I am not too happy about it, I have also
> > added a rewind() when Bacula releases the tape
> > before acquiring the next tape. That should "unfreeze"
> > the drive. I don't like the rewind because it can
> > potentially be time consuming, and if the user 
> > really wants it he could use the non-rewinding
> > drive.  Just the same, if that corrects this
> > problem, then at least for the moment I'll leave
> > the rewind in.
> > 
> > Best regards,
> > 
> > Kern
> > 
> > On Mon, 2003-05-12 at 17:49, Dan Langille wrote:
> > > On 10 May 2003 at 10:18, Kern Sibbald wrote:
> > > 
> > > > After looking over the code, I see that if you have not
> > > > configured the device to do an offline on closing, Bacula
> > > > simply closes the device without rewinding it. If one does a
> > > > strict interpretation of your kernel output, the error would
> > > > have then persisted from one tape to another (not really
> > > > correct). Whatever the case may be, I've now added code to
> > > > Bacula to rewind the drive before releasing it when it is
> > > > asking for another tape.
> > > > 
> > > > If your kernel supports MTIOCLRERR, Bacula does issue that
> > > > command (ioctl()) after any such error attempting to clear the
> > > > error condition.  However, that function is not implemented on
> > > > all systems.  If there is some other way of doing it on your
> > > > system, please let me know and I'll add the code.
> > > 
> > > I could find no reference to MTIOCLRERR in either the mtio or
> > > the ioctl man pages.  But I did speak with a FreeBSD coder about
> > > this issue. I suggest asking on the freebsd-scsi at freebsd.org
> > > mailing list. They're a very helpful group.
> > 
> > 
> 


------- End of forwarded message -------
-- 
Dan Langille : http://www.langille.org/