XPWRITE data integrity

George Penokie gop at us.ibm.com
Tue Dec 16 06:58:21 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 0052335A86256DFE_=
Content-Type: text/plain; charset="us-ascii"


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 0052335A86256DFE_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Jim,</font>
<br>
<br><font size=2 face="sans-serif">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>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Jim.Coomes at seagate.com</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/15/2003 04:28 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</font>
<br></table>
<br>
<br>
<br><font size=2 face="Courier New">* 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<br>
</font>
<br>
<br>
--=_alternative 0052335A86256DFE_=--




More information about the T10 mailing list