Add Immediate bit to XPWRITE and XDWRITE Extended commands
Gerry_Houlder at notes.seagate.com
Tue Jul 9 14:35:03 PDT 1996
* 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
>>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
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
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
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
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
greatly improved if the RAID controller wants to take a little more risk and
more trust in the drive to protect against loss of cached write data. This is
of us want -- better performance with negligible loss of data security. Chris's
enough merit to warrant discussion in this arena.
More information about the T10