From owner-freebsd-scsi@FreeBSD.ORG Mon May 12 12:45:29 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F363437B401 for ; Mon, 12 May 2003 12:45:28 -0700 (PDT) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id F17AD43FAF for ; Mon, 12 May 2003 12:45:27 -0700 (PDT) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 93C443D28 for ; Mon, 12 May 2003 15:45:26 -0400 (EDT) From: "Dan Langille" To: freebsd-scsi@freebsd.org Date: Mon, 12 May 2003 15:45:24 -0400 MIME-Version: 1.0 Message-ID: <3EBFC194.23070.5D6681F1@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: do we have MTIOCLRERR on ioctl? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2003 19:45:29 -0000 Anyone any any ideas about this issue? ------- Forwarded message follows ------- Subject: Re: [Bacula-users] Too many errors trying to mount From: Kern Sibbald To: Dan Langille Copies to: bacula-users 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/