Add Immediate bit to XPWRITE and XDWRITE Extended commands

[Gerry Houlder]

* From the SCSI Reflector, posted by:
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
*
This is a response to part of Steve Holmstead's posting:

>>As an example, consider a 4 drives plus parity situation. If all 4 drives 
need 
>>to be written using XDWRITE command the command sequence would be as follows:
>>(1) An XDWRITE command is issued to a data drive.
>>(2) An XDREAD command is issued to return the xor data to the initiator.
>>(3) An XPWRITE command is issued to write the xor data to the parity drive.
>>(4) Steps 1 through 3 are repeated for each of the data drives.
>
>A better example:
>(1) An XDWRITE is sent to each of the 4 drives.
>(2) An XDREAD is sent to each of the 4 drives.
>(3) The initiator sends a SINGLE XPWRITE to the parity drive containing the
>    data from the 4 XDREADs.

The "better example" suggested by Steve would require the RAID controller to
xor the 4 chunks of data together (4 chunks returned by the XDREAD commands)
as step 2.5 so that only one chunk of data (in XPWRITE command) needs to be
sent to the parity drive. The first example assumes the RAID controller depends 
on
the drive to do all xor operations. This is why the xor commands were created.

>This example does assume a sequential operation in a RAID-4 environment.
>These assumptions were extracted from reading Gerry's text on his example
>of how to make the performance better.

This situation can also occur in a RAID-5 environment. Within a defined 
redundancy
stripe, updates to each of the four data drives can result in access to a common
area on the fifth drive for parity. These may not represent sequential addresses
in the logical address space of the array, but it is possible.

>My bottom line opinion (if anyone cares, and I doubt they do) is that I am
>STRONGLY opposed to adding an immediate bit to the XOR commands.  I
>am similarly opposed to using WCE bit to control XOR command flow.  I
>feel that by doing so opens that ugly mess about DEFERRED ERRORS and
>system data integrity.

I care very much that Steve took the time to give his opinion. I believe 
Steve's opinion
is shared by many in the RAID community. This is why the XPWRITE command was
defined with wording requiring that the data be written to disk before 
returning GOOD
status. This is much more secure than write caching. Chris Burns correctly
observed that this level of security can result in lower performance, which can 
be
greatly improved if the RAID controller wants to take a little more risk and 
have
more trust in the drive to protect against loss of cached write data. This is 
what all
of us want -- better performance with negligible loss of data security. Chris's 
idea has
enough merit to warrant discussion in this arena.