Write incompatibility - choose recovery by sense key?

Greg_Smith%LEGACY at wine.expsys.com Greg_Smith%LEGACY at wine.expsys.com
Thu Sep 26 12:13:24 PDT 1996


* From the SCSI Reflector (scsi at symbios.com), posted by:
* Greg_Smith%LEGACY at wine.expsys.com
*




          >* PAT LaVarre <LAVARRE at IOMEGA.COM>
          >Might be fun to write down some of the
          >unwritten rules of SCSI, eh?

          >I thought one of these was to not tie error
          >recovery to anything more detailed than the
          >sense key - has that idea vanished into
          >obsolescence?

          >Yes, please, please do log the detail, but
          >only use the detail in an analysis that
          >includes inside knowledge of the firmware
          >revision disclosed by the x12 inquiry
          >string?

          >The idea of basing choices only on the SK
          >forms part of the rationale for using SK x2
          >for something that never will be ready i.e.
          >a completely incompatible format but SK x7
>for something that is partially usable i.e.
>a non-writable format.

Hmmm... briefly I was thinking about the concept
of adding an optional READ ERROR DETAIL command
to SPC... This would be useful to integrators
trying to interpret an unexpected error code.
Suppose you are trying to tailor your driver code
to deal with specific ASC/ASCQ combos from a
specific drive or set of drives, and
you get one you don't understand. You can
do a READ ERROR DETAIL which would return
an ASCII string in the data. Most drives
have lots of ROM these days...

The thing is, new devices will be designed
which have issues not anticipated by existing
standards. The "can't write this particular
format medium at all" case is a good example.
The tape drive "Can't write starting here" is
another. Who knows what issues new technologies
will have? "Can't read backwards while the klystron
temperature is this high" (Oh.. that's why
it's busy.. I can try again but in the meantime
I'll turn on the enclosure fans).

My point is, the ASC ASCQ combination is supposed
to provide more specific detail but it can never
be totally general if it has to rely on standard codes.
I guess this sort of thing is supposed to be in
the OEM manual where integrators can find it,
but this approach allows the code itself to
supply the information, which also means it
will be correct for the firmware rev.

Drive designers would pick the most reasonable SK/ASC /ASQ
combo and then generate a detail message which explained the
exact problem.

OK, i'll stop now.... :-)


*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list