Date: Thu, 11 Mar 1999 09:35:17 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Tom Torrance at home <tom@tomqnx.com> Cc: scsi@freebsd.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs Message-ID: <Pine.LNX.4.04.9903110856040.28526-100000@feral-gw> In-Reply-To: <m10L8Bw-000I0zC@TomQNX.tomqnx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> How about the following? > > 1) Receive the error. > 2) Verify that it is not a harmless device quirk. > 3) Map the error back to the application for action. > 4) Until the application or the operator does something positive to > re-establish positioning, greet further attempts to write with a > media write-protected error. > 5) It might be possible to allow the tape operator a mechanism to > turn off the condition (the 'ignore' option) in some harmless > way. Perhaps an 'mt status'? Steps 1-4 was exactly what I was proposing. The positive steps can be by the operator via mt(1) or via a backup program. Step 5 I hadn't considered. Would a config option for the kernel be okay for this (e.g., SA_PASSIVE_DRIVER)? > There might be some actions that would/should be allowable, like > writing tape marks - you would be much better qualified to judge those. Hmm. I'd think not. > > On the face of it, though, this approach might satisfy your concerns > (and mine). The downside is all the queries you might receive from > people puzzled as to why they would suddenly get a media write- > protected error from a tape that they have been happily writing to... > Good explanations/instructions in the error logs would help in > this regard. Yes. This is something I often fail to do. It's hard to figure out who the audience is in some of these systems. > Particular care should be taken that only the problem > device/app is affected for systems with multiple tape drives. Obviously. > > Obviously something like this would have to be properly tested with > the most common backup systems to ensure that there is not some > potentially harmful application interaction. > > What do you think? > Good positive suggestions. To summarize: + We agree for steps 1-4. + Step 5 could be a config option (?) + The man pages should explain these actions. I don't want to go too far with this. I'm just trying to stabilize *this* driver. I'm more interested in seeing whether a new driver based upon the TapeAlert working group proposals (see http://www.hp.com/tape/tapealert) is worth doing. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9903110856040.28526-100000>