XPWRITE data integrity (and 03-381r0)

Gerry.Houlder at seagate.com Gerry.Houlder at seagate.com
Fri Dec 19 15:31:27 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*

By the way, Keith, the backup / restore operation you describe here that
isn't restored to the same LBA it was backed up from (thus resulting in
mis-matched reference tags) can be recovered by using the 32 byte commands
that allow for specifying a non-interlocked reference tag value. This is a
new reason for those commands that was not brought up during earlier
discussions.

On the CRC seed value subject, I have heard some tape folks indicate that
most new tape drives implement block addressing commands. I have heard
statements that all new tape drives support this command mode. This makes
the tape look more like a fixed block device (at least in terms of the data
block that are read and written). Does this partly negate the concern about
not knowing the length of each block, since it is usually known for such
cases? Is the length concern mostly about older backups make with devices
that don't support the fixed block mode and new backups that choose not to
use the block mode even if it is available on the device? Could we expect
that tapes that know about E2E feature will always use fixed block
addressing? Also if a tape is used to back up a disk, wouldn't the fixed
length blocks from the disk always result in the same fixed block size
being present on the tape (unless compression is used)?



                                                                                                                       
                      "Holt, Keith"                                                                                    
                      <kholt at lsil.com>         To:       "'George Penokie'" <gop at us.ibm.com>                           
                      Sent by:                 cc:       T10 Reflector <t10 at t10.org>                                   
                      owner-t10 at t10.org        Subject:  RE: XPWRITE data integrity (and 03-381r0)                     
                      No Phone Info                                                                                    
                      Available                                                                                        
                                                                                                                       
                      12/19/2003 02:21                                                                                 
                      PM                                                                                               
                                                                                                                       
                                                                                                                       




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>                   To:        T10 Reflector            
    Sent by: owner-t10 at t10.org <t10 at t10.org>                               
                                       cc:                                 
                                       Subject:        RE: XPWRITE data    
    12/18/2003 01:22 PM        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          To:        T10 Reflector          
                                 <t10 at t10.org>                            
                                        cc:                               
    12/15/2003 04:28 PM                 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







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




More information about the T10 mailing list