XPWRITE data integrity (and 03-381r0)

George Penokie gop at us.ibm.com
Thu Dec 18 12:21:09 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <gop at us.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 006FBFBA86256E00_=
Content-Type: text/plain; charset="us-ascii"


Keith, 

So is the next step to obsolete from SCSI all non-block devices because
block devices don't need to communicate with those lowly tape devices. 

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880





	"Holt, Keith" <kholt at lsil.com> 
Sent by: owner-t10 at t10.org 


12/18/2003 01:22 PM 
        
        To:        T10 Reflector <t10 at t10.org> 
        cc:         
        Subject:        RE: XPWRITE data integrity (and 03-381r0) 





I want to call attention to an important characteristic of the simple
function.  As Jim pointed out, if you use a seed of zero, you can still
check the data guard.  By using a seed of zero, the XOR'd CRC of all the
data drives is, by definition, equivalent to the CRC that is calculated
|from the data in the parity drive.  You can still check the CRC without
performing any additional operations. 

This benefit is realized if and only if we stick with our original plan
of record to use zero for the seed for CRC calculations.  A seed of zero
was chosen for block storage data guards specifically for this reason.
There is a proposal from Rob Elliott on the agenda for the January CAP
meeting, 03-381r0, SBC-2 Data Protection CRC Seed, that proposes that
the seed for block storage E2E protection be changed to 1-seeded and
transmitted inverted, solely because it's beneficial for tape devices.
In his proposal, Rob acknowledges that a benefit is lost to a RAID set
implementing RAID 5 if the proposed change is implemented.  This same
benefit would be lost to the XPWRITE simple function, as well. 


I can't dispute that it would simplify things for the HBA if disk and
tape E2E protection used identical CRC generation methods.  Neither can
I dispute that having a non-zero seed would be better for tape devices.
However, no one has attempted to dispute the fact that zero-seeded is
better for a block storage specification.  It seems to me that requiring
disk devices to use non-zero seeds vs. requiring tape devices to use a
zero seed are roughly equivalent trade-offs.  Being more interested in
block storage devices, I am obviously going to argue that we shouldn't
have to change the seed for block storage E2E protection because it
offers some incremental benefit to tape devices, at the expense of
losing protection on block storage RAID set commands. 


Keith 


-- 
Keith Holt 
LSI Logic Storage Systems Inc. 
keith.holt at lsil.com 
316-636-8665 


-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com]
Sent: Tuesday, December 16, 2003 8:58 AM
To: Jim.Coomes at seagate.com
Cc: owner-t10 at t10.org; T10 Reflector
Subject: RE: XPWRITE data integrity


Jim, 

I vote for simple. The end-to-end protection is primarily for end-to-end
protection not side-to-side protection (e.g., RAID-5). If it happens to
help out on side-to-side protection then that's nice but I see no reason
to add in complexity to accomplish that.

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880





	Jim.Coomes at seagate.com 
Sent by: owner-t10 at t10.org 


12/15/2003 04:28 PM         
       To:        T10 Reflector <t10 at t10.org> 
       cc:         
       Subject:        RE: XPWRITE data integrity 





* From the T10 Reflector (t10 at t10.org), posted by:
* Jim.Coomes at seagate.com
*
The incorporation of the data integrity proposal into SBC-2 raises a
question: how does XPWRITE function with data integrity? Below are
several
possible approaches. Please voice your opinions to the reflector or to
me
offline.

Simple function

The simple approach would be to require the protection information on
the
parity drive be the XOR product of the protection information on the
data
drives. In this case, little checking of the protection information is
possible. The only checking may be the guard field if the CRC is not
seeded.

With this XPWRITE function the protection information for a failed data
drive would be regenerated the same way as the user data, XOR product of
the parity drive and the remaining data drives.

Robust function

To validate the transfer of data to and from the parity drive, the same
functionality as for normal writes and reads could be required. The 3
bit
WRPROTECT field could be added to the XPWRITE command. The parity drive
would check the protection information as specified by the WRPROTECT
field.
The parity drive would write the protection information to the media
without XORing with the previous protection information. A read access
to
the parity drive could check the protection information as specified by
the
RDPROTECT field in the read command.

With this XPWRITE function the protection information for a failed data
drive would have to be recalculated.

Jim Coomes

952-402-2665



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org





--=_alternative 006FBFBA86256E00_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Keith,</font>
<br>
<br><font size=2 face="sans-serif">So is the next step to obsolete from SCSI all non-block devices because block devices don't need to communicate with those lowly tape devices. <br>
<br>
Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208<br>
External: 507-253-5208 &nbsp; FAX: 507-253-2880<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Holt, Keith" <kholt at lsil.com&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: owner-t10 at t10.org</font>
<p><font size=1 face="sans-serif">12/18/2003 01:22 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;T10 Reflector <t10 at t10.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: XPWRITE data integrity (and 03-381r0)</font>
<br></table>
<br>
<br>
<br><font size=2 face="Arial">I want to call attention to an important characteristic of the simple function. &nbsp;As Jim pointed out, if you use a seed of zero, you can still check the data guard. &nbsp;By using a seed of zero, the XOR'd CRC of all the data drives is, by definition, equivalent to the CRC that is calculated from the data in the parity drive. &nbsp;You can still check the CRC without performing any additional operations.</font>
<p><font size=2 face="Arial">This benefit is realized if and only if we stick with our original plan of record to use zero for the seed for CRC calculations. &nbsp;A seed of zero was chosen for block storage data guards specifically for this reason. &nbsp;There is a proposal from Rob Elliott on the agenda for the January CAP meeting, 03-381r0, SBC-2 Data Protection CRC Seed, that proposes that the seed for block storage E2E protection be changed to 1-seeded and transmitted inverted, solely because it's beneficial for tape devices. &nbsp;In his proposal, Rob acknowledges that a benefit is lost to a RAID set implementing RAID 5 if the proposed change is implemented. &nbsp;This same benefit would be lost to the XPWRITE simple function, as well.</font>
<p><font size=2 face="Arial">I can't dispute that it would simplify things for the HBA if disk and tape E2E protection used identical CRC generation methods. &nbsp;Neither can I dispute that having a non-zero seed would be better for tape devices. &nbsp;However, no one has attempted to dispute the fact that zero-seeded is better for a block storage specification. &nbsp;It seems to me that requiring disk devices to use non-zero seeds vs. requiring tape devices to use a zero seed are roughly equivalent trade-offs. &nbsp;Being more interested in block storage devices, I am obviously going to argue that we shouldn't have to change the seed for block storage E2E protection because it offers some incremental benefit to tape devices, at the expense of losing protection on block storage RAID set commands.</font>
<p><font size=2 face="Arial">Keith</font>
<p><font size=2 face="Arial">-- <br>
Keith Holt</font><font size=3> </font><font size=2 face="Arial"><br>
LSI Logic Storage Systems Inc.</font><font size=3> </font><font size=2 face="Arial"><br>
keith.holt at lsil.com</font><font size=3> </font><font size=2 face="Arial"><br>
316-636-8665</font><font size=3> </font>
<p><font size=2 face="Tahoma">-----Original Message-----<b><br>
From:</b> George Penokie [mailto:gop at us.ibm.com]<b><br>
Sent:</b> Tuesday, December 16, 2003 8:58 AM<b><br>
To:</b> Jim.Coomes at seagate.com<b><br>
Cc:</b> owner-t10 at t10.org; T10 Reflector<b><br>
Subject:</b> RE: XPWRITE data integrity<br>
</font>
<br><font size=2 face="sans-serif"><br>
Jim,</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
I vote for simple. The end-to-end protection is primarily for end-to-end protection not side-to-side protection (e.g., RAID-5). If it happens to help out on side-to-side protection then that's nice but I see no reason to add in complexity to accomplish that.<br>
<br>
Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208<br>
External: 507-253-5208 &nbsp; FAX: 507-253-2880<br>
</font><font size=3><br>
<br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=3%>
<td width=40%><font size=1 face="sans-serif"><b>Jim.Coomes at seagate.com</b></font><font size=3> </font><font size=1 face="sans-serif"><br>
Sent by: owner-t10 at t10.org</font><font size=3> </font>
<p><font size=1 face="sans-serif">12/15/2003 04:28 PM</font><font size=3> </font>
<td width=56%><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp; &nbsp;T10 Reflector <t10 at t10.org&gt;</font><font size=3> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=3> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: XPWRITE data integrity</font><font size=3> </font></table>
<br><font size=3><br>
<br>
</font><font size=2 face="Courier New"><br>
* From the T10 Reflector (t10 at t10.org), posted by:<br>
* Jim.Coomes at seagate.com<br>
*<br>
The incorporation of the data integrity proposal into SBC-2 raises a<br>
question: how does XPWRITE function with data integrity? Below are several<br>
possible approaches. Please voice your opinions to the reflector or to me<br>
offline.<br>
<br>
Simple function<br>
<br>
The simple approach would be to require the protection information on the<br>
parity drive be the XOR product of the protection information on the data<br>
drives. In this case, little checking of the protection information is<br>
possible. The only checking may be the guard field if the CRC is not<br>
seeded.<br>
<br>
With this XPWRITE function the protection information for a failed data<br>
drive would be regenerated the same way as the user data, XOR product of<br>
the parity drive and the remaining data drives.<br>
<br>
Robust function<br>
<br>
To validate the transfer of data to and from the parity drive, the same<br>
functionality as for normal writes and reads could be required. The 3 bit<br>
WRPROTECT field could be added to the XPWRITE command. The parity drive<br>
would check the protection information as specified by the WRPROTECT field.<br>
The parity drive would write the protection information to the media<br>
without XORing with the previous protection information. A read access to<br>
the parity drive could check the protection information as specified by the<br>
RDPROTECT field in the read command.<br>
<br>
With this XPWRITE function the protection information for a failed data<br>
drive would have to be recalculated.<br>
<br>
Jim Coomes<br>
<br>
952-402-2665<br>
<br>
<br>
<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org</font><font size=3><br>
<br>
</font>
<br>
<br>
--=_alternative 006FBFBA86256E00_=--




More information about the T10 mailing list