Add Immediate bit to XPW

Wed Jul 10 08:54:07 PDT 1996

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

Gerry,

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!

Jim

--------------------------------------
Date: 7/9/96 12:50 PM
To: Jim McGrath
From: Gerry Houlder
Received: by qm_smtpgw.qntm.com with SMTP;9 Jul 1996 12:50:17 U
Received: from worf.qntm.com (worf-gw.qntm.com) by mail.qntm.com with ESMTP
	(1.37.109.16/16.2) id AA071701872; Tue, 9 Jul 1996 12:51:12 -0700
Received: from mpdgw2.symbios.com by worf.qntm.com with ESMTP
	(1.37.109.16/16.2) id AA082960335; Tue, 9 Jul 1996 12:25:38 -0700
Received: (from root at localhost) by mpdgw2.symbios.com (8.6.8.1/8.6.6) id
NAA22646; Tue, 9 Jul 1996 13:19:08 -0600
Received: from aztec.co.symbios.com(153.72.199.214) by mpdgw2.symbios.com via
smap (V1.3)
	id smab22551; Tue Jul  9 13:18:35 1996
Received: (from majordom at localhost) by Symbios.COM (8.6.8.1/8.6.6) id NAA17427
for scsi-outgoing; Tue, 9 Jul 1996 13:16:59 -0600
Received: from mpdgw2.symbios.com ([204.131.201.2]) by Symbios.COM
(8.6.8.1/8.6.6) with ESMTP id NAA17418 for <scsi at symbios.com>; Tue, 9 Jul 1996
13:16:56 -0600
Received: (from root at localhost) by mpdgw2.symbios.com (8.6.8.1/8.6.6) id
NAA22100 for <scsi at symbios.com>; Tue, 9 Jul 1996 13:16:56 -0600
Received: from ns1.seagate.com(204.160.183.10) by mpdgw2.symbios.com via smap
(V1.3)
	id sma022001; Tue Jul  9 13:16:44 1996
Received: (from smap) by ns1.seagate.com (8.6.12/cf-v5) id MAA14257 for
<scsi at symbios.com>; Tue, 9 Jul 1996 12:18:24 -0700
Received: from unknown(134.204.114.75) by ns1 via smap (V1.3)
	id sma014231; Tue Jul  9 19:17:50 1996
Received: from notes.seagate.com (sv-mis4.stsv.seagate.com [134.204.14.86]) by
ns.seagate.com (8.6.12/cf-v5) with SMTP id MAA19704 for
<@ns.seagate.com:scsi at symbios.com>; Tue, 9 Jul 1996 12:17:56 -0700
Received: by notes.seagate.com (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 notes.seagate.com>
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 notes.seagate.com>
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 notes.seagate.com>
*
This proposal (document 96-194) will be introduced at the Colorado Springs
SCSI 
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.
The 
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 
completed.

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
returns 
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
returned 
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
sends 
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
added 
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
and 
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
the 
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
same 
retention and safety requirements as regular write data.

An advantage for the WCE bit alternative is that the controller wouldnt have
to 
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
feel 
comfortable with it. Even if we decide that the XPWRITE command should make
use 
of the WCE bit, some changes to the standard will probably be needed. The
model 
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.