XPWRITE data integrity (and 03-381r0)

Holt, Keith kholt at lsil.com
Fri Dec 19 12:21:21 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_01C3C66D.AAE48506
Content-Type: text/plain;
	charset="ISO-8859-1"

George,
 
It was not my intent to imply that tape devices are lower forms of life
that are not worthy of end-to-end data protection.  Far from it.  In
fact, I would like to see some way to preserve the block storage data
guard across backup/restore operations.  As discussed in the November
CAP meeting, it's not feasible to expect to preserve the Reference Tag,
since the file will likely be restored to a different logical block
address, perhaps even to a different logical unit altogether.  The data
guard, on the other hand, could reasonably be preserved while moved from
disk to tape, then back again.  I look forward to seeing some specific
proposals regarding E2E protection for tape devices on how
variable-length block tape E2E protection could be applied while
preserving fixed-length block disk E2E protection.
 
Since I obviously didn't get my point across the way I intended, I'll
try again.  Please find a way of adding E2E protection to tape command
sets that doesn't require a dilution of E2E protection for RAID sets
that utilize the block storage command set.
 
Regards,
 
Keith Holt 

-- 
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: Thursday, December 18, 2003 2:21 PM
To: Holt, Keith
Cc: owner-t10 at t10.org; T10 Reflector
Subject: RE: XPWRITE data integrity (and 03-381r0)



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






------_=_NextPart_001_01C3C66D.AAE48506
Content-Type: text/html;
	charset="ISO-8859-1"

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

 George,
  
 It was not my intent to imply that tape devices are lower forms of life that are not worthy of end-to-end data protection.  Far from it.  In fact, I would like to see some way to preserve the block storage data guard across backup/restore operations.  As discussed in the November CAP meeting, it's not feasible to expect to preserve the Reference Tag, since the file will likely be restored to a different logical block address, perhaps even to a different logical unit altogether.  The data guard, on the other hand, could reasonably be preserved while moved from disk to tape, then back again.  I look forward to seeing some specific proposals regarding E2E protection for tape devices on how variable-length block tape E2E protection could be applied while preserving fixed-length block disk E2E protection.
  
 Since I obviously didn't get my point across the way I intended, I'll try again.  Please find a way of adding E2E protection to tape command sets that doesn't require a dilution of E2E protection for RAID sets that utilize the block storage command set.
  
 Regards,
  
 Keith Holt -- 
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: Thursday, December 18, 2003 2:21 PM
To: Holt, Keith
Cc: owner-t10 at t10.org; T10 Reflector
Subject: RE: XPWRITE data integrity (and 03-381r0)



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





------_=_NextPart_001_01C3C66D.AAE48506--




More information about the T10 mailing list