SBC-3 Read Defect Data - Defect List Not Found
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>
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).
9700 Village Center Drive
Granite Bay, CA 95746
> -----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
> 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
> 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
> 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
> Read Defect 10 CDB:
> "A REQ_PLIST bit set to zero and a REQ_GLIST bit set to zero specifies
> the device server shall return only the defect list header (i.e., the
> four bytes of the defect list)."
> It also goes on to say:
> "If the requested defect list format and the returned defect list format
> 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
> RECOVERED ERROR and the additional sense code set to DEFECT LIST NOT
> 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
> than the requested defect list format, should a device still return this
> RECOVERED ERROR check condition? My take would be that it should return
> 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
> * 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