XPWRITE data integrity (and 03-381r0)

Charles Binford Charles.Binford at sun.com
Tue Dec 23 13:55:56 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* Charles Binford <Charles.Binford at Sun.COM>
*
This is a multi-part message in MIME format.

--Boundary_(ID_XannFHep/CWSdLcYVn4Iqg)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

I'm trying to figure out why we have to have the *same* CRC-seed for
both disk and tape.  Based on this and other responses I've see so far
it doesn't sound like the disk CRC is going to make it to the tape
unchanged.  

I suggested the idea of having different CRC-seeds for disk and tape
during the CAP discussion in November, but let me recap it down here.
First, my assumptions of a typical implementation:


*	CRC checking generation done in protocol chip (e.g. FC chip)
*	CRC checking/generation enabled, disabled on a PER IO request
basis.  In other words, what and how to check is set in some flag field
of the protocol chip IO request data structure.

I'm suggesting one could have one of those "what and how to check" flags
be which CRC seed to use.  If I were writing the driver, I'd have a flag
in my data structure associated with the LU that told me how to set the
crc-seed flag for the protocol chip.   

In general I usually go with fewer, not more, options.  However, I feel
that given the trade-offs on this particular subject I'd go with the
option.
Charles Binford
p.s.   I'm heading on vacation / holiday so I'll be slow in responding
to any comments.


RRose at exabyte.com   wrote:


On Read operations, most tape drives do support some means of
block-level addressing; however, the blocks are still variable sized.
The device typically implements some combination of indexing, heuristics
and counting blocks along a track to locate a specific block.

Tape drives are not normally block addressable on Write operations;
although, there are exceptions with varying restrictions.  The
compromises to permit block-addressable writes may include a preset
fixed-block size, preformatted tapes, significant loss of capacity to
provide splice points and significantly decreased I/O throughput.

Also, the fact that a disk is fixed block doesn't imply that the backup
will be fixed block, since the blocks on tape consist data from multiple
disk blocks and possibly multiple disk drives.  A disk block may contain
fragments from several files.  On a file-by-file backup, these fragments
are gathered from wherever they reside and sent to the backup device.
There may also be header labels, trailer labels and
application-generated indexes which are likely to be of a different
size.

Until some form of an O/S-independent standard tape file system gains
broad acceptance, variable-length tape blocks are pretty much needed for
portability between O/S's and app's.  People expect that data written
|from their proprietary-O/S mainframes be readable on their
different-proprietary-O/S pc's and workstations.  There may be solutions
which don't involve a tape filesystem or variable-length blocks, but
some broadly-implemented, O/S-independent, standard method of encoding
the exact length of each item of data needs to exist.

-roger rose 
 Exabyte Corp. 

> -----Original Message----- 
> From: Gerry.Houlder at seagate.com   [
mailto:Gerry.Houlder at seagate.com  ] 
> Sent: Friday, December 19, 2003 4:31 PM 
> To: t10 at t10.org <mailto:t10 at t10.org>  
> Subject: RE: XPWRITE data integrity (and 03-381r0) 
> 
> 
> * From the T10 Reflector ( t10 at t10.org <mailto: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  <mailto:t10 at t10.org> <t10 at t10.org>

>                       owner-t10 at t10.org <mailto: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 <mailto: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 <mailto:owner-t10 at t10.org>
<mailto: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 <mailto: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 <mailto:owner-t10 at t10.org>
To:        T10 
> Reflector          
>                                   <mailto:t10 at t10.org> <t10 at t10.org>

>             
>                                         cc:                   
>             
>     12/15/2003 04:28 PM                 Subject:        RE: 
> XPWRITE data  
>                                  integrity                    
>             
>                                                               
>             
> 
> 
> 
> 
> 
> 
>       * From the T10 Reflector ( t10 at t10.org <mailto: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 <mailto: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
<mailto:majordomo at t10.org>  
> 



-- 

Charles Binford
Sun Microsystems
Wichita, KS 67226
316.315.0382 x222


--Boundary_(ID_XannFHep/CWSdLcYVn4Iqg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

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

 I'm trying to figure out why we have to have the *same* CRC-seed for both disk and tape.  Based on this and other responses I've see so far it doesn't sound like the disk CRC is going to make it to the tape unchanged.  

I suggested the idea of having different CRC-seeds for disk and tape during the CAP discussion in November, but let me recap it down here.  First, my assumptions of a typical implementation:
 CRC checking generation done in protocol chip (e.g. FC chip) CRC checking/generation enabled, disabled on a PER IO request basis.  In other words, what and how to check is set in some flag field of the protocol chip IO request data structure. I'm suggesting one could have one of those "what and how to check" flags be which CRC seed to use.  If I were writing the driver, I'd have a flag in my data structure associated with the LU that told me how to set the crc-seed flag for the protocol chip.   

In general I usually go with fewer, not more, options.  However, I feel that given the trade-offs on this particular subject I'd go with the option.
 Charles Binford
 p.s.   I'm heading on vacation / holiday so I'll be slow in responding to any comments.
 

RRose at exabyte.com wrote:
 RE: XPWRITE data integrity (and 03-381r0) On Read operations, most tape drives do support some means of block-level addressing; however, the blocks are still variable sized.  The device typically implements some combination of indexing, heuristics and counting blocks along a track to locate a specific block. Tape drives are not normally block addressable on Write operations; although, there are exceptions with varying restrictions.  The compromises to permit block-addressable writes may include a preset fixed-block size, preformatted tapes, significant loss of capacity to provide splice points and significantly decreased I/O throughput. Also, the fact that a disk is fixed block doesn't imply that the backup will be fixed block, since the blocks on tape consist data from multiple disk blocks and possibly multiple disk drives.  A disk block may contain fragments from several files.  On a file-by-file backup, these fragments are gathered from wherever they reside and sent to the backup device.  There may also be header labels, trailer labels and application-generated indexes which are likely to be of a different size. Until some form of an O/S-independent standard tape file system gains broad acceptance, variable-length tape blocks are pretty much needed for portability between O/S's and app's.  People expect that data written from their proprietary-O/S mainframes be readable on their different-proprietary-O/S pc's and workstations.  There may be solutions which don't involve a tape filesystem or variable-length blocks, but some broadly-implemented, O/S-independent, standard method of encoding the exact length of each item of data needs to exist. -roger rose 
 Exabyte Corp. > -----Original Message----- 
> From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com] 
> Sent: Friday, December 19, 2003 4:31 PM 
> To: t10 at t10.org 
> Subject: RE: XPWRITE data integrity (and 03-381r0) 
> 
> 
> * 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 
> 

-- 
CB Email Signature Charles Binford
 Sun Microsystems
 Wichita, KS 67226
 316.315.0382 x222
 


--Boundary_(ID_XannFHep/CWSdLcYVn4Iqg)--




More information about the T10 mailing list