Recent XOR Comments

Jay Elrod Jay_Elrod at
Wed Jan 4 08:38:50 PST 1995

This is in response to a recent message on the reflector regarding
the XOR document.

George Penokie wrote:

>Below is attached a proposal for changes to the XOR proposal.  It is based
>on 94-111r2 because this is the latest document that has been distributed
>to the committee.
>I am concerned about the XOR working not following X3T10 procedures for
>document distrubution.  It appears, from the minutes, that either a new
>rev of 94-111 was distrubuted or a new proposal was distributed that
>contained infromation on a new mode page and that new information was
>not made available for the last mailing.
>Because of the lack of documentation on this new mode page it is impossible
>to say anything about it.  So although statements about there being
>aggrement within the XOR meetings are good, the fact that no one outside of the
>few people who were able to attend those meetings have seen it or discussed it
>indicates it has not had the scrutiny it should have had.

Regarding document distribution, George is right - I apologize for not seeing
to it that the document was included in the last mailing. (A working copy of the
document was placed on the SCSI BBS on December 16 for review by those
interested - unfortunately, I just learned today, the transfer to the BBS was
unsuccessful). We will make sure the document is included in the next mailing.
If there is an urgent need for one in the mean time, send me a note, and I can
send one to you (overnight, fax, etc.).

It should be emphasized that interested parties are encouraged to attend the
XOR study group meetings. The last two meetings were well attended and
embraced with excellent discussion. The next meeting is on Monday, January 9
|from 1:00 - 5:00 during the ANSI meetings at Tahoe.

>         Date:  Dec 21, 1994                      X3T10/95-108 rev 0
>         To:  X3T10 Committee (SCSI)
>         From:  George Penokie (IBM)
>         Subject:  Comments on RAID 5 Support on SCSI Disk Drives
>         (94-111r2)
>         1-The XDWRITE command does not follow the conventions set
>         down within the SPC standard.  It does not even follow the
>         conventions set down within the XOR document.  I suggest the
>         following (or something like this) for the XDWRITE CDB
>         format:
>         Byte    Description
>         0       Op Code
>         1       No Change
>         2-5     No Change (Logical Block Length)
>         6-7     Reserved
>         8-9     Parameter List Length (Bytes)
>         10-11   Reserved
>         12-13   Transfer Length (Blocks)
>         14      Reserved
>         15      Control
>         The parameter list would contain the secondary address and
>         secondary logical block address.  Now the secondary address
>         can be any size you want.  The CDB follows the same format
>         as defined in the Rebuild and Regenerate commands and is SPC
>         compatible.

With regard to the XDWRITE command not following "...conventions set down
within the XOR document", I'm not sure what "conventions" are being referred
to. The only convention set down within the document is the command itself.

With regard to the XDWRITE command not following "...conventions set down
within the SPC standard", the current proposed format of the XDWRITE command
comes as close as we could make it to following the SPC standard, while keeping
the Secondary Address and Secondary LBA in the CDB. George's suggestion
is not a bad one, and we have, in the past, thought about the possibility of 
the secondary address information as command parameters. The disadvantage
to this approach is that the XDWRITE target is then held off from sending the
secondary command until it has received the XDWRITE parameters. In some
configurations this could be a considerable wait. We feel it makes sense to get
the secondary target started on any necessary command activity (seek, for
example) as soon as possible. Thus the inclusion of the Secondary Address and
Secondary LBA in the CDB. As always (so far anyway), nothing is in stone here,
but it makes sense to us and those who have been involved in the development
of the XOR document to do it this way.

>         2-The CONTROL part of the CONTROL byte includes the Flag and
>         Link bits so those bits should not appear in this proposal.

The Flag and Link bits can be removed. They're leftovers from the earlier days 
the document. They'll be taken out.

>         3-The format of the SECONDARY ADDRESS field and the SOURCE
>         ADDRESS field are not defined.  So I have no way of knowing
>         how many bytes is enough to address all the devices. I do
>         know that in SCC you can address all devices in a single
>         layer with two bytes.  And since the XOR proposal is only
>         addressing a single layer I do not understand why you would
>         need a different addressing protocol than is already
>         defined in SCC.

The formats of the Secondary Address and the Source Address fields are not
defined because they will vary depending on the physical interface. In a
traditional SCSI bus topology, one byte is sufficient. In Fibre Channel, up to 
bytes can be required. In other interfaces more bytes may be required. I will 
a note to this effect.

Thanks to George for his observations and comments.

Jay Elrod

More information about the T10 mailing list