Tape drives returning sense on every command

Dave, dtn:237-6877 15-Feb-1994 1116 cressman at elwood.enet.dec.com
Tue Feb 15 08:41:56 PST 1994

Jeff Stai wrote:

>From:	US3RMC::"stai at dt.wdc.com" "Jeff Stai" 11-FEB-1994 23:12:22.91
>To:	starch::monia
>CC:	scsi at WichitaKS.NCR.COM, asami at dt.wdc.com, worrell at dt.wdc.com
>Subj:	Re: Open issues from January 11 SAM working group
>Regarding item 1: I tend to prefer option b), even if the protocol does
>not support autosense. I recall, however, that way back in the deep
>dark mists of early SCSI-1, we had a status code of "RECOVERED ERROR"
>(code 0x01). It really meant "not an error, but I do have sense data if
>you want it". I just mention it as a possibility if folks really want
>a general solution.
>In any case the tape guys should be chiming in here. It seems that a
>good tape implementation would perhaps want to return sense on EVERY
>command, to return the state of Filemark and EOM, etc. Perhaps we need
>a (shudder) MODE parameter to select the behavior?

    As a designer/implementer of DLT tape SCSI code, I have some comments
    to the above:

    1. I agree with what John L. wrote about Recovered Error sense data
       availability being indicated by a check condition status.  This
       is alive and well in SCSI-2.  For tapes, if the normal soft error
       rate begins to grow beyond normal levels, it seems to me that its
       usually good for the device to start reporting something to the 
       host/user.  This is done with Check Condition, SenseKey=RecoveredError.
       This gives the user the opportunity to take appropriate action, or
       at least to watch the unit more closely. This is under control of the
       Mode Sense/Sel PER bit, of course.  Most disks have similiar capability
       for reporting ECC recovered sectors.  This mechanism can also be
       used to report SCSI bus errors that were recovered from, and any other
       type of recovered error event in the subsystem.

    2. A good tape implemenation should *not* return sense on every command,
       I think.  In SCSI1/2 it is generally way too much overhead.  For fast
       hosts, and/or perhaps serial scsi, this may be less of an issue, but
       still a concern, and still not necessary.  Current position might
       actually be more interesting to some applications, but that is best
       returned in ReadPosition data, not Sense data.

    -Dave Cressman
    Digital Equipment Corp
    DLT development
    cressman at elwood.enet.dec.com

More information about the T10 mailing list