Add Immediate bit to XPW

Jim McGrath jmcgrath at QNTM.COM
Wed Jul 10 08:54:07 PDT 1996

* From the SCSI Reflector, posted by:
* "Jim McGrath" <jmcgrath at>
        Reply to:   RE>Add Immediate bit to XPWRITE and XDWRITE Extended


I like the idea of using the WCE bit a lot better than using the immediate
bit.  I also agree with Dal that the whole concept would appear to be of
very high risk if ever used in an environment where power failures
are possible.

Why don't people just do command queuing instead?  Then you get the
same effect of 4 immediate writes with 4 queued writes, and yet
correct status is always sent back to the host when the write is
completed - all the performance with none of the risk!


Date: 7/9/96 12:50 PM
To: Jim McGrath
From: Gerry Houlder
Received: by with SMTP;9 Jul 1996 12:50:17 U
Received: from ( by with ESMTP
	( id AA071701872; Tue, 9 Jul 1996 12:51:12 -0700
Received: from by with ESMTP
	( id AA082960335; Tue, 9 Jul 1996 12:25:38 -0700
Received: (from root at localhost) by ( id
NAA22646; Tue, 9 Jul 1996 13:19:08 -0600
Received: from by via
smap (V1.3)
	id smab22551; Tue Jul  9 13:18:35 1996
Received: (from majordom at localhost) by Symbios.COM ( id NAA17427
for scsi-outgoing; Tue, 9 Jul 1996 13:16:59 -0600
Received: from ([]) by Symbios.COM
( with ESMTP id NAA17418 for <scsi at>; Tue, 9 Jul 1996
13:16:56 -0600
Received: (from root at localhost) by ( id
NAA22100 for <scsi at>; Tue, 9 Jul 1996 13:16:56 -0600
Received: from by via smap
	id sma022001; Tue Jul  9 13:16:44 1996
Received: (from smap) by (8.6.12/cf-v5) id MAA14257 for
<scsi at>; Tue, 9 Jul 1996 12:18:24 -0700
Received: from unknown( by ns1 via smap (V1.3)
	id sma014231; Tue Jul  9 19:17:50 1996
Received: from ( []) by (8.6.12/cf-v5) with SMTP id MAA19704 for
< at>; Tue, 9 Jul 1996 12:17:56 -0700
Received: by (IBM OS/2 SENDMAIL VERSION 1.3.17/1.0)
	  id AA3968; Tue, 09 Jul 96 12:14:20 -0700
Message-Id: <9607091914.AA3968 at>
Received: by SEAGATE (Lotus Notes Mail Gateway for SMTP V1.1) id
  EC1CA516BFD83A088625636100748C01; Tue,  9 Jul 96 12:14:19 EDT
To: scsi <scsi at Symbios.COM>
From: Gerry Houlder <Gerry_Houlder at>
Date:  9 Jul 96 14:12:37 EDT
Subject: Add Immediate bit to XPWRITE and XDWRITE Extended commands
Mime-Version: 1.0
Content-Type: Text/Plain
Sender: owner-scsi at Symbios.COM
Precedence: bulk

* From the SCSI Reflector, posted by:
* Gerry Houlder <Gerry_Houlder at>
This proposal (document 96-194) will be introduced at the Colorado Springs
Working Group meeting (July 16-17). Comments are welcome at the meeting or on 
this reflector.

Date:  July 9, 1996
To: X3T10 Committee
From: Gerry Houlder, Seagate Technology
Subj: Add Immediate bit to XPWRITE and XDWRITE Extended commands

The need for this feature was identified by Chris Burns (Maximum Strategy) in 
reflector messages and follow up phone calls with me. He is concerned about 
poor performance in situations where several (and particularly if all) data 
drives that have the same parity drive need to be updated at the same time.
parity drive will be a bottleneck in this situation.

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.

This sequence results in 2 commands (one XDWRITE and one XDREAD) being issued 
to each data drive and 4 XPWRITE commands to the parity drive. If each XPWRITE

command has to write the xor result to the drive before doing the next XPWRITE

command, at least one extra disk revolution will be lost on each XPWRITE 
command. Performance would be better if the first 3 XPWRITE commands left the 
resulting parity data in cache and returned GOOD status without writing the 
data to disk. The last XPWRITE would write the data to disk when it is 

Chris suggests using a bit in the command block to indicate that the data 
shouldnt be written to disk yet. If the bit is one, the XPWRITE command
GOOD status as soon as the xor operation is complete and doesnt attempt to 
write the data to disk. If the bit is zero, then GOOD status cannot be
until the data has been written to disk. This  conforms to the existing 
requirements on this command.

This feature must also work with the XDWRITE Extended command. A system that 
uses XDWRITE Extended would use the following command sequence:
(1) An XDWRITE extended command is issued to a data drive. The data drive
XPWRITE command to parity drive. When XPWRITE returns status, data drive 
returns status to the controller.
(2) Controller repeats step 1 for each of the data drives.

In order to make use of the XPWRITE immediate feature, a bit must also be
to the XDWRITE Extended command. That way the bit can be carried over to the 
XPWRITE command that is issued by the data drive. This would be used in the 
same way: the first 3 XDWRITE Extended commands would set the immediate bit
the last command would have the bit cleared so it would cause the data to be 
written to disk.

There is an alternative that must also be discussed. We could generalize the 
use of the WCE bit in Mode Page 8 so that it applies to XPWRITE commands as 
well as regular write commands. This would be a reasonable extension because 
the xor data that is left in cache after completion of the xor operation is
same as the data written to disk. Therefore it is safe to let it be used to 
satisfy a read request for that LBA (as a cache hit) and otherwise has the
retention and safety requirements as regular write data.

An advantage for the WCE bit alternative is that the controller wouldnt have
be concerned with which of the xor commands executes first or last. The 
disadvantage is that there is no assurance that the parity drive wont try to 
write the data to disk before the last command is received. There is also no 
assurance the data will be written to disk as soon as the last command has 
completed. RAID controllers like to know (and exert control over) exactly when

data is written to disk. That is why Chris Burns prefers adding a bit to the 
xor commands -- it provides explicit control over the write operation.

The WCE bit option should only be persued if the RAID controller companies
comfortable with it. Even if we decide that the XPWRITE command should make
of the WCE bit, some changes to the standard will probably be needed. The
for xor commands will need to be updated to describe how write caching can be 
used to help certain xor operations and cannot be used for others.

More information about the T10 mailing list