In the general case, there is no longer any way to know for sure what the structure of the
correction code is on the actual disk or which part of that structure will be
revealed to you by a READ LONG.  Vendors now use a huge combination of
tools to create reliable data recovery.
 
So you have two choices:
 
    a)  Contact the vendor and see if he will tell you how to parse the
        READ LONG returned data.  He probably will do so only under NDA.
 
    b)  Do a WRITE to a block.  Then do a READ LONG to the block and
        see what comes back.  Note that it may have no relationship to the
        write if there are internal block correction codes being used.
        Then to test error recovery, do a WRITE LONG to the block using
        the data just read with one or more bits changed.  A subsequent
        READ to the block should provide information about the error
        and its recoverability, though it may show up only in a log page.
 
If I were a disk drive vendor, I would be pushing for making READ/WRITE LONG obsolete.
 
Of course for RAID devices, this question is even more (and less) interesting.
 
Bob


From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of Bill.Martin@emulex.com
Sent: Thursday, September 18, 2008 10:10 AM
To: t10@t10.org
Subject: Number of ECC bytes

I have looked and not found a mechanism for determining the number of ECC bytes per logical block on an attached device.  Is there any place in any mode page that this information is available, or any other mechanism to determine this information?  I know that READ LONG allows reading of this information, but it is vendor specific where this information is, and there is no information in the return about what portion of the additional data is ECC and what portion is WRProtect etc.

 

Thanks for any input.

 

Bill Martin

Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin@emulex.com