Proposal to add a new modifier to SCSI Write commands.

David_Cohen at stratus.com David_Cohen at stratus.com
Fri Nov 29 06:32:19 PST 1996


* From the SCSI Reflector (scsi at symbios.com), posted by:
* David_Cohen at stratus.com
*
I disagree with the proposal to eventually remove the support for read and write
long commands.  The forced error bit in the write command seems interesting, but
you will not be able to get the full power of this funtionality that currently
exists with the read and write long commands.

Currently, these commands are very usefull for evaluating the robustness of the
drive's error recovery and ecc algorithms.  It gives you the ability to create
any bit pattern of bit length error, creating 01/18 or 03/11 errors, and
determining the actual correction span of the disk under varying bit patterns.

If the drive vendor implements this force error bit, how do you know what they
are doing, since every vendor's ecc and ercovery algorithm's are different?  How
do you know how any bits they are corrupting?  How do you know if they corrupt
the ecc bits, or the data bits?  How do you know anything?  And what if the way
they do it is not acceptable for you?

Also, the statement that 

>     - It is relatively difficult to determine the transfer length that the
>       device supports for Read Long.

It not correct.  All you have to do is sent the command with the transfer length
of the formatted block length of the drive, and you will get an illegal command
error, you look at the residue field in the request sense info, and then you can
calculate the ecc length that gets added to the block length in the read and
write long cdb.

Also, the statement

>     - It is impossible for the Initiator to be certain that a particular
>       Write Long data pattern will generate a subsequent read error.  This
>       is because the error correction algorithms are complex and are not
>       known by the host (nor should they be).

Is incorrect as well.  You can expose the entire correction span by turning EER
off and PER on.  Then issue read and write long commands starting with a 1 bit
error, and keep incrementing by additional bit errors.  At first you will see 
'hidden recoveries', then at a certain bit error length you will start to see
01/18 errors, then eventually you will see 03/11 errors.  This allows you to see
the full ranges of the drive's recovery algorithms.


And lastly, the statement

>     - Storage vendors are growing reluctant to support Read and Write Long,
>       because they expose the internals of the error detection scheme which
>       are usually vendor specific and subject to change.

This is good to expose the internals.  If the particular vendor has a very good
algorithm than they will shine and look superior to their competitors when the
drive is analyzed using the read and write long commands.  Conversely, if they
have a poor implementation, they will not look competitive.  It does not really
expose any of the actual design or specific internals, but rather shows the
result of the design and the capability of the drive.  If a vendor wants to hide
this, as an OEM I would be suspicious.

In conclusion,

I suppose for unsophisticated users, that want a simplistic way of creating bad
blocks for whatever pupose, the force error bit, could be useful.

But, if you are not sophisticated in your design and engineering dept, you
probably should not be playing with this stuff in the first place.  For
sophiticated OEMs, this feature is very important.

Dave


> 
> To: SCSI @ Symbios.COM @ gw
> cc:  (bcc: Joseph Glider/Almaden/IBM)
> Subject: Proposal to add a new modifier to SCSI Write commands.
> 
> * From the SCSI Reflector (scsi at symbios.com), posted by:
> * coughlan at star.zko.dec.com (Tom)
> *
>    Some implementations of disk mirroring use the SCSI Write Long
>    command.  Write Long is used to propagate an unrecovered read error
>    from one member of the mirror set to all the other members.  This
>    ability to create error-for-error identical volumes is an important
>    feature for some mirror set implementations.  There are some
>    problems, though, with the Write Long mechanism:
> 
>     - It is impossible for the Initiator to be certain that a particular
>       Write Long data pattern will generate a subsequent read error.  This
>       is because the error correction algorithms are complex and are not
>       known by the host (nor should they be).
> 
>     - Storage vendors are growing reluctant to support Read and Write Long,
>       because they expose the internals of the error detection scheme which
>       are usually vendor specific and subject to change.
> 
>     - It is relatively difficult to determine the transfer length that the
>       device supports for Read Long.
> 
>    Because of these issues, Read Long and Write Long are on many people's
>    list of commands that should be obsoleted eventually.
> 
>    I would like to propose an alternative to the Write Long mechanism to
>    provide the "forced error" behavior.  The idea is to add a bit to the
>    Write commands that instructs the drive to force an ECC error for all
>    subsequent reads of the block.  The drive is free to implement this
>    command in any convenient way, provided that all subsequent reads
>    result in a "Medium Error", "Unrecovered Read Error".  A subsequent write
>    to the block with the "force error" bit clear would return the block to
>    normal status.  Write commands with the "force error" bit set will be
>    restricted to one block transfer lengths.
> 
>    This would allow us to phase out Read Long and Write Long, while
>    improving the function they provide today for mirroring.  Target devices
>    should (not required) implement the Command Support Inquiry data, so
>    that the initiator will be able to easily determine whether the new
>    Write bit is supported.
> 
>    The cost is the addition of a bit-check to every Write command.
>    Checking the bit wouldn't be too costly, though, since it could be
>    checked for zero at the same time that the other bits in the Write
>    CDB are checked.
> 
>    In the interest of full disclosure:
>    ---------------------------------
>    Digital holds a patent on a technique for forcing errors that is similar
>    to the one described here.  It has been determined that this proposal
>    does not infringe on the Digital patent.  This determination must be
>    reassessed if the current proposal is modified.
> 
> 
>    I'd like to request that this topic be added to a future Working
>    Group agenda.
> 
>    Thanks.
> 
>    Tom Coughlan
>    OpenVMS SCSI Project Leader
>    Digital Equipment Corporation
>    Nashua, New Hampshire
>    tom.coughlan at zko.mts.dec.com
>    603-881-0933
> *
> * For SCSI Reflector information, send a message with
> * 'info scsi' (no quotes) in the message body to majordomo at symbios.com
> 
> 
> 
> *
> * For SCSI Reflector information, send a message with
> * 'info scsi' (no quotes) in the message body to majordomo at symbios.com
> 
> 

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




More information about the T10 mailing list