XPWRITE data integrity (and 03-381r0)

Holt, Keith kholt at lsil.com
Thu Dec 18 11:22:47 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Holt, Keith" <kholt at lsil.com>
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3C59C.521325E4
Content-Type: text/plain;
	charset="ISO-8859-1"

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





------_=_NextPart_001_01C3C59C.521325E4
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

 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




------_=_NextPart_001_01C3C59C.521325E4--




More information about the T10 mailing list