Issues with 99-179r1 "Hard Drive Self-Tests"
Hallam, Ken J
Ken.Hallam at UNISYS.com
Thu Jun 3 07:59:25 PDT 1999
* From the T10 Reflector (t10 at symbios.com), posted by:
* "Hallam, Ken J" <Ken.Hallam at unisys.com>
I will add my 2-cents and side with Ralph. A drive that delays responding to
normal commands for up to 2 minutes will break 2 different O/S environments
within my company. And guess what the O/S will do if it encounters a
timeout? Why, Bus Reset of course! Thus this proposal has the potential to
create chaos in our environment.
Kenneth J. Hallam
Director of Technology
25725 Jeronimo Road M/S 201
Mission Viejo, CA 92691
Tel: 949-380-5115, Fax: 949-380-5858
ken.hallam at unisys.com
> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber at csi.com]
> Sent: Wednesday, June 02, 1999 3:41 PM
> To: Mark Evans; T10, Reflector
> Subject: Issues with 99-179r1 "Hard Drive Self-Tests"
> * From the T10 Reflector (t10 at symbios.com), posted by:
> * Ralph Weber <ralphoweber at csi.com>
> I have a couple of big problems and a couple of nits with
> the Hard Drive Self-Tests proposal (T10/99-179r1).
> Big Problems:
> 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.
> The only fix I can think of, short of changing host software,
> is returning BUSY status.
> 2) While my opinion is not cast in stone, I'm really worried
> about the changes to REQUEST SENSE. I admit that REQUEST SENSE
> looks like a convenient place to put this progress indication
> feature. But, selecting a REQUEST SENSE behavior based on a
> bit in the CDB is a really big change. At a minimum, lots more
> band aids will have to be applied to the REQUEST SENSE definition
> text. Also, the proposed text:
> "When STPI is zero the device server shall not return the
> PROGRESS INDICATION field."
> breaks the heck out of returning progress indications for FORMAT
> Lastly, I'm wondering if anybody has considered the interactions
> between these changes and RBC.
> Options appear to be making these changes fit the current REQUEST
> SENSE progress indication model (i.e., working without the new CDB
> bit), or putting the progress indication in the log page, which will
> be bad for RBC disks because RBC doesn't have log pages.
> 3) The ASC/ASCQ mentioned in the second paragraph of 3.2 must
> be changed
> to match the one shown in note 3 of table 4.
> 4) The last sentence before clause 7 needs to be clarified:
> "When the IMMED bit is set to one and the self-test routine
> fails, the device server shall log the self-test results and
> shall create a deferred error."
> 4a) 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.
> 4b) 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?
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at symbios.com
* 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