Date: Mon, 12 May 2003 15:45:24 -0400 From: "Dan Langille" <dan@langille.org> To: freebsd-scsi@freebsd.org Subject: do we have MTIOCLRERR on ioctl? Message-ID: <3EBFC194.23070.5D6681F1@localhost>
next in thread | raw e-mail | index | archive | help
Anyone any any ideas about this issue? ------- Forwarded message follows ------- Subject: Re: [Bacula-users] Too many errors trying to mount From: Kern Sibbald <kern@sibbald.com> To: Dan Langille <dan@langille.org> Copies to: bacula-users <bacula-users@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@freebsd.org > > > mailing list. They're a very helpful group. > > > > > ------- End of forwarded message ------- -- Dan Langille : http://www.langille.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EBFC194.23070.5D6681F1>