From owner-freebsd-scsi Mon Mar 1 12:18:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (Postfix) with ESMTP id B64A915399 for ; Mon, 1 Mar 1999 12:18:27 -0800 (PST) (envelope-from tom@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m10HZ8T-000I1kC; Mon, 1 Mar 1999 15:17:53 -0500 (EST) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: RELENG_3 sa0 driver In-Reply-To: from Matthew Jacob at "Feb 28, 1999 12:16:38 pm" To: mjacob@feral.com Date: Mon, 1 Mar 1999 15:17:53 -0500 (EST) Cc: tom@tomqnx.com, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2279 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I cannot reproduce this problem. Are you sure that it wasn't an I/O error > which caused the tape to rewind? I did put in code that tries to unload > the tape after an error that can cause an uncertainty in position. I'm pretty positive, Matt - no I/O errors. Also it works consistently the same with different tapes. However, you will remember that you decided to take the route of allowing (but ignore) the prevent/allow media removal command to the HP T4000s although it doesn't handle it. It would be greatly preferable to have the 'quirk' for the T4000s prevent the issuance of the command, if that is possible. It is quite possible that your routine is interpreting the ignored invalid command as an I/O error. Other 'quirks' for other units could produce the same results. If I might venture an opinion, the driver is the wrong layer to take this kind of decision. "dump" is supposed to make its own decisions about fault tolerance on I/O errors. If you don't agree, there should definitely be a nice "big" error message if that were to legitimately be done. Even that is not too good as someone running X would not see the message. The "dump" program should abort if its media is removed from play... For other reasons, I scraped this system down to the "bare metal" and loaded RELEASE-3.1 on it. The "dump" program running with /dev/nrsa0 definitely rewinds as part of the end of job "close" function. It is (and was with Feb 25 RELENG_3) demonstrable here with: dump 0abuf 64 /dev/nrsa0 / (that "dump" program has a pretty non-standard command line interface!!) It hangs on the CLOSE console comment waiting for the rewind to complete before giving the command prompt. Unless it has been fixed since 3.1 it is the same still. Regards, Tom > > > > On Fri, 26 Feb 1999, Tom Torrance at home wrote: > > > I cvsup'd and rebuilt my system last night. > > Today, I did a system backup, and discovered that > > although dump was using /dev/nrsa0, the tape was automatically > > rewinding when closed. Easy to miss, and pretty dangerous > > when multi-file backup tapes are involved. > > > > Cheers, > > Tom > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-scsi" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message