Issues with 99-179r1 "Hard Drive Self-Tests"

Gene_Milligan at notes.seagate.com Gene_Milligan at notes.seagate.com
Thu Jun 3 07:55:20 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* Gene_Milligan at notes.seagate.com
*
<<1) The whole notion that a drive doing background self tests can
delay responses to regular commands for two seconds is going to
break the command timeout mechanism is most host device drivers.
Most host drivers timeout commands for which responses have not
been received in 30 seconds (sometimes less).  If the device
really takes 2 minutes, there are going to be command timeouts
(and probably bus resets) flying all over the place.>>

     Did you really mean a big issue with the 2 seconds in the proposal or
your inadvertent 2 minutes. I agree with your agony over 2 minutes, that is
why it is 2 seconds.

     If in fact you meant 2 seconds, a remedy for that is for the driver
not to initiate this function if it is not prepared to comply with the
requirements.

<<But, selecting a REQUEST SENSE behavior based on a
bit in the CDB is a really big change.>>

     Isn't this behavior just an extension of the format progress report
that has been in the standard for years? I assume the driver/software
issuing the REQUEST SENSE is part of the diagnostic system package that
specializes in this behavior.

<< "When STPI is zero the device server shall not return the
   PROGRESS INDICATION field."

breaks the heck out of returning progress indications for FORMAT
commands.>>

     Ralph has a good point that needs to be dealt with. Perhaps "When STPI
is zero the device server shall not return the drive self-test PROGRESS
INDICATION field."

<<Does 'log the self-test results' refer to the log page?  If
yes, specific details (or a pointer to already written specific
details) should be added.>>

     The details are elsewhere in the proposal and a reference can be added
although this may be easier for the editor to handle since I presume the
proposal references do not port well to the draft.

<<Is it possible or necessary to provide guidance on the
sense key and additional sense information to be provided in
the deferred error the device server is required to create?>>

     Surely it is possible but I wonder if it is practical. I assume when
something breaks the firmware takes whatever knowledge of the broken item
and looks up the available code equating to that wound. If a new way to
break is invented the designer sends a request to T10 to have a new code
added and T10 either agrees or points out that the designer missed an
equivalent definition already available.

Gene






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





More information about the T10 mailing list