SBC-3 Read Defect Data - Defect List Not Found

Mike Berhan mikeb at bustrace.com
Thu Jun 12 12:01:44 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
Rob,
Thank you for your reply.  Gotcha on the sense code clarification.
I'm not sure where you stand though on the part of software just requesting
the header.  I think you are stating that even if the software is just
requesting the header, if a *different* defect list format is returned than
what was requested, then the drive should always return that recovered error
check condition?  Would this be the expected behavior?
>From the host side, the recovered error itself seems redundant to me.	The
return header tells us all we need to know.  That must be the thinking of a
drive I have here that never returns that recovered error check condition
regardless of the plist/glist/fmt settings (even though this clearly
violates the "shall" requirements of the specification).
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
> -----Original Message-----
> From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]
> Sent: Thursday, June 12, 2008 11:53 AM
> To: Mike Berhan; t10 at t10.org
> Subject: RE: SBC-3 Read Defect Data - Defect List Not Found
> 
> Since the DEFECT LIST FORMAT in the header is not what was requested, the
> RECOVERED ERROR is still helpful.  It guides the application client to
request
> a different format the next time, when there might actually be some defect
> list entries.
> 
> Think of "DEFECT LIST NOT FOUND" as "requested defect list not found" and
the
> name makes more sense.
> 
> ---
> Rob Elliott, HP Industry Standard Server Storage
> 
> 
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mike
Berhan
> Sent: Thursday, June 12, 2008 11:23 AM
> To: t10 at t10.org
> Subject: SBC-3 Read Defect Data - Defect List Not Found
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Mike Berhan" <mikeb at bustrace.com>
> *
> In reviewing SBC-2 and SBC-3, the following statement is made regarding
the
> Read Defect 10 CDB:
> 
> "A REQ_PLIST bit set to zero and a REQ_GLIST bit set to zero specifies
that
> the device server shall return only the defect list header (i.e., the
first
> four bytes of the defect list)."
> 
> It also goes on to say:
> 
> "If the requested defect list format and the returned defect list format
are
> not the same, the device server shall transfer the defect data and then
> terminate the command with CHECK CONDITION status with the sense key set
to
> RECOVERED ERROR and the additional sense code set to DEFECT LIST NOT
FOUND."
> 
> My question is this.	If you are only requesting the header (i.e.
> REQ_PLIST=0 and REQ_GLIST=0), and the return defect list format is
different
> than the requested defect list format, should a device still return this
> RECOVERED ERROR check condition?  My take would be that it should return
no
> check condition (since no defect data was requested) but I can see how
> someone could interpret it the other way.
> 
> As a side note, a "DEFECT LIST NOT FOUND" error is not as accurate as a
> "DEFAULT DEFECT LIST FORMAT RETURNED" (if there were such a sense code).
> I'm not requesting the addition of a new sense code.	Just an observation.
> 
> -------
> Mike Berhan
> busTRACE Technologies
> 9700 Village Center Drive
> Suite 50-F
> Granite Bay, CA  95746
> 916.773.4554 phone
> 916.218.6283 fax
> http://www.bustrace.com
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list