Data Integrity telecon, Oct 29 - Tape Issues discussion

Elliott, Robert (Server Storage) elliott at hp.com
Sat Nov 1 14:28:27 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C3A0C7.78A24759
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

For a tape restore to a disk, where the destination LBAs are different
than the original (e.g. a file restore or an image restore to a
different base LBA), it seems like this mode might be needed for the
disk writes:
a) check the guard
b) do not check the app tag
c) do not check the ref tag
=20
Unfortunately, that combination is not available with the WRPROTECT
field in the WRITE (10)(12)(16) commands proposed in 03-365.  You can
turn off all three together, but that loses the guard checking (which =
is
still important on its own).
=20
The WRITE (32) command in 03-307 could be used with:
a) WRPROTECT mode 10b (do not check ref tag, check guard, check app =
tag)

b) app tag mask set to 0000h so the app tag is also not checked
=20
However, that cannot be done with WRITE (10)(12)(16).
=20
Is it acceptable to force backup apps and copy managers to use the 32
byte commands, or should the WRPROTECT field be expanded to 3 bits to
support this?
=20
Similarly, the READ (10)(12)(16) commands have no way to read data =
while
only checking the guard.  If a backup application does an image restore
to a new base LBA, then wants to walk through the file system metadata
and adjust all the LBAs to the new offsets (and fill in the correct new
ref tag values), it won't be able to read data from the aforementioned
write with guard checking unless it uses READ (32).  This is not as bad
as the write situation, since the important read check is by the
application client/initiator doing the read, not the device
server/target providing the read data.  You lose the fault isolation
benefits, however.
=20
--=20
Rob Elliott, elliott at hp.com=20
Hewlett-Packard Industry Standard Server Storage Advanced Technology=20
https://ecardfile.com/id/RobElliott
<https://ecardfile.com/id/RobElliott> =20


-----Original Message-----
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]=20
Sent: Wednesday, October 29, 2003 4:57 PM
To: T10, Reflector
Cc: 'Michael Banther'; Erich Oetting; Paul Entzel; Paul Suhler; Tuong
Vu; Dave Peterson
Subject: Data Integrity telecon, Oct 29 - Tape Issues discussion



At the Data Integrity telecon we discussed tape issues as they relate =
to
this proposal.=20

The statement was made that the assumptions listed in the note below =
are
incorrect.=20
1) The Application Tag is unused,=20
2) The Reference Tag (the one associated with the LBA) is:=20

a.	Only associated to the LBA by the first Write command of a file.
<< NOT TRUE >>=20

b.	Only associated to the LBA by the first Read command of a file.
<< NOT TRUE >>=20

c.	The application client does not compare the Reference Tag of the
Read command back to the Reference Tag of the Write command. << NOT =
TRUE
if LBA tag is locked >>=20

There was much discussion about how the onus of ensuring that data
protect survives through a backup/restore lies with the backup/restore
application.  The belief is that most, if not all, that is needed is
provided to allow this to occur.  It would require the backup
application to embed meta-data in the data stream backup up.  This =
would
allow the restore application to have information necessary to
regenerate the disk guard meta-data.  However, it is believed that
something more is needed.=20

If legacy commands are used then the application tag and reference tag
are set to all 1's and the owner software should know not to check =
them.
However, if it doesn't do this the data will become unusable.=20

The belief was expressed that for backup it would need to backup 520
bytes (512 bytes plus meta-data), preserve the application tag, and
modify the ref tag on the restore depending on LBA tag locked or not,
and regenerate the guard (CRC).=20

There were a number of proposals needed, of which the following are =
what
I captured.=20
1) Need method to retrieve the meta-data for legacy devices.=20
2) The CRC needs to be seeded with 1's to allow for variable length
blocks and leading 0's (Rob was going to handle this one)=20
3) Changes are needed for Extended Copy=20
4) For tape to extend this concept to tape, SSC-3 changes will be
needed. (Kevin Butt will handle this one in the future)=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=20
Jim,=20

I think this discussion about end-to-end and how it would affect
backup/restore operations needs to be discussed.=20

First of all, variable length commands are not just a potential.  They
are reality.   Different block sizes are used during typical backups
(e.g. the last block of a file is usually a different length than the
rest, as well as headers and trailers).  Also, many ISVs use different
block sizes.  We have customers who also use overlength and underlength
transfers as a normal mode of operation.  I'm sure that has not been
considered.  CRC must be seeded by 1's to be able to handle variable
length blocks.=20

Keep in mind, however, that the current data protection proposals =
ignore
tape altogether.  In fact, the authors indicated that they took a look
at Extended Copy and determined it was difficult to make work and they
weren't interested in it so they decided to ignore it and let anybody
interested in Extended Copy worry about it.  I have an action from the
rest of the tapeheads to express our concerns and try to bring an
understanding to the tape world as well as to the disk world of how =
this
data protection will effect backup/restore operations and how
backup/restore operations will effect end-to-end data protection.  =20

Included herein is a summary of tape issues and pieces of some of the
conversations I've had with tape (that's me + the tape people present =
at
the last ADI telecon), ISV people from one ISV (guess which one), and
disk people.=20

Assumptions:=20
a) One of the concerns was what happened when a disk crashed and a
defrag occurred and how that effects LBA.  I've been informed that the
defrag is really a file system issue and as such is an operating system
concept that is outside the disk drive.  So this will have no bearing =
on
LBA's. - Is this also true for RAID?=20
b) Backup/Restore software currently does the equivalent of a meta-data
transform today.  The software reads the data and the blocks to tape =
are
different sizes than blocks read from disk.  To use disk block sizes
would severely degrade performance.=20
c) Software today uses two different types of operations for
backup/restore.  They are 1) request a file from the OS, and 2) Image
backup/restore where they use the actual LBA's.  These LBA's can be
restored to different locations than from where they were read from.
Some examples are restoring to a different size disk than from which it
was backed up, the OS modifying its filesystem.=20

These commands are only SBC-2 and any talk of tape commands would need
to be deferred to proposals to be brought in for inclusion in SSC-3 =
that
would allow tape to play in the same arena.  The issue I am trying to
focus on is making sure that a legacy backup/restore to tape=20
1) can still occur (which I think it can with loss of protection across
tape) and=20
2) that when a legacy backup/restore to tape occurs that it doesn't
break the scheme such that when the application client reads the data
|from the restored disk with the new data protection it doesn't cause =
the
application client to call the data bad.=20
3) that the Extended Copy command can still be used.=20

Hopefully I can clear up some confusion.  I can envision three types of
tape backup:=20
<<  =3D=3D=3D> Is this section between '<<' and '>>' true? =
<=3D=3D=3D=3D=20
All of my notes assume and RELY on:=20
1) The Application Tag is unused,=20
2) The Reference Tag (the one associated with the LBA) is:

a.	Only associated to the LBA by the first Write command of a file.


b.	Only associated to the LBA by the first Read command of a file.=20

c.	The application client does not compare the Reference Tag of the
Read command back to the Reference Tag of the Write command.=20
During a backup/restore operation there is potential that the LBA's =
used
on the Restore will be different from those used on the Backup.  =
Indeed,
this is the crux of the concerns related to interoperability issues =
with
Tape or any other Backup/Restore device.  If the Reference to the LBA =
is
done in such a manner as to tie the data to the same LBA that was used
on the initial Write, then this will not survive through a
Backup/Restore operation. Indeed if any one of the above assumptions =
are
not reality, then I see no guarantee that data could survive through a
Backup/Restore operation.=20
>>=20

<<Mode 1 would nominally not have protection to tape.  However,
proprietary data protection schemes that may be available from some =
tape
vendors may be used to get a near end-to-end data protection but would
be susceptible to the process that converted the disk protection scheme
into the tape protection scheme>>=20
1. Mode 1 - where only the block data (typically 512 bytes) is written
to and read from tape.  The software which reads and writes the disk =
has
to know the disk block size and LBA, and can therefore check the CRC =
and
Reference Tag  on disk reads and generate CRC and Tag on disk writes.
This is true as long as the Reference Tag Seed is the existing LBA in
today's CDB.  This is one reason IBM does not want a new Reference Tag
Seed in a new 32 byte CDB.=20

The issue here is the Application Tag, which would be lost, but that is
true for legacy disk I/O operations as well.=20

<<Mode 2 would nominally not have protection to tape.  However,
proprietary data protection schemes that may be available from some =
tape
vendors may be used to ensure a full end-to-end data protection >>2.
Mode 2 - where both the block data (typically 512 bytes) plus the eight
check bytes is written to and read from tape.  The software (as with
mode 1) could check the CRC and Tag on disk reads.  The data block plus
check bytes could be written to and read from tape (as raw data).  The
disk controller could check the CRC and Tag on the disk writes.=20

<<Mode 3 would have to wait for additions to SSC-3 and may need
modifications to the concept listed>> 3. Mode 3 - where both the block
data (typically 512 bytes) plus the eight check bytes is written to and
read from tape plus checked.  The software (as with mode 1) could check
the CRC and Tag on disk reads.  The data block plus check bytes could =
be
written to and read from tape (as with mode 2).  The disk controller =
(as
with mode 2) could check the CRC and Tag on the disk writes.=20

In order for tape to check the CRC, tape would need to know the disk
logical block size.  This would allow the SSC streaming commands to be
used to transfer multiple disk blocks as a single tape block and
maintain a high data rate.  In order for tape to check the Tag, tape
would need to know the disk LBA.  The software which reads and writes
the disk has to know the disk LBA, but a new mechanism would be needed
to pass this information to tape.  This would be a very complex
operation of checking data in the middle of a block and I believe there
would be resistance to this as well as possible technical limitations.=20

I think the software (or tape device driver) would need to create tape
specific guard data around the tape block.  The user data, from the =
tape
perspective would be the disk user data plus the disk meta-data.  I
don't know how having multiple [data + CRC] sets would work in
validating the tape block CRC since the value would go to zero several
times throughout a single block.

Kevin D. Butt
Fibre Channel & SCSI Architect, IBM Tape Microcode,=20
6TYA, 9000 S. Rita Rd., Tucson, AZ  85744
Tie-line 321; Office: 520-799-5280, Lab: 799-5751, Fax: 799-4138, =
Email:
kdbutt at us.ibm.com=20



------_=_NextPart_001_01C3A0C7.78A24759
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

Message For a=20 tape restore to a disk, where the destination LBAs are different than = the=20 original (e.g. a file restore or an image restore to a different base = LBA), it=20 seems like this mode might be needed for the disk = writes:
 a)=20 check the guard
 b) do=20 not check the app tag
 c) do=20 not check the ref tag
  
 Unfortunately, that combination is not available with the = WRPROTECT field=20 in the WRITE (10)(12)(16) commands proposed in 03-365.  You can = turn off=20 all three together, but that loses the guard checking (which is still = important=20 on its own).
  
 The=20 WRITE (32) command in 03-307 could be used with:
 a)=20 WRPROTECT mode 10b (do not check ref tag, check guard, check app=20 tag) 
 b) app tag mask set to 0000h so the app tag is also not=20 checked
  
 However, that cannot be done with WRITE = (10)(12)(16).
  
 Is it=20 acceptable to force backup apps and copy managers to use the 32 byte = commands,=20 or should the WRPROTECT field be expanded to 3 bits to support=20 this?
  
 Similarly, the READ (10)(12)(16) commands have no way to read = data while=20 only checking the guard.  If a backup application does an image = restore to=20 a new base LBA, then wants to walk through the file system metadata and = adjust=20 all the LBAs to the new offsets (and fill in the correct new ref tag = values), it=20 won't be able to read data from the aforementioned write with guard = checking=20 unless it uses READ (32).  This is not as bad as the write = situation, since=20 the important read check is by the application client/initiator doing = the read,=20 not the device server/target providing the read data.  You lose = the fault=20 isolation benefits, however.
  
 -- = 
Rob Elliott, = elliott at hp.com=20 
Hewlett-Packard = Industry Standard=20 Server Storage Advanced Technology 
https://ecardfile.com/id/Ro= bElliott=20 


-----Original Message-----
From: = Kevin D Butt=20 [mailto:kdbutt at us.ibm.com] 
Sent: Wednesday, October 29, = 2003 4:57=20 PM
To: T10, Reflector
Cc: 'Michael Banther'; = Erich=20 Oetting; Paul Entzel; Paul Suhler; Tuong Vu; Dave = Peterson
Subject:=20 Data Integrity telecon, Oct 29 - Tape Issues=20 discussion



At the Data=20 Integrity telecon we discussed tape issues as they relate to this=20 proposal. 

The = statement was made=20 that the assumptions listed in the note below are incorrect. = 
1) The Application Tag is=20 unused, 
2) The=20 Reference Tag (the one associated with the LBA) is:=20 Only = associated to=20 the LBA by the first Write command of a file. << NOT TRUE=20 >>=20 Only = associated to=20 the LBA by the first Read command of a file. << NOT TRUE=20 >>=20 The = application=20 client does not compare the Reference Tag of the Read command back = to the=20 Reference Tag of the Write command. << NOT TRUE if LBA tag is = locked=20 >> 

There = was much=20 discussion about how the onus of ensuring that data protect = survives through=20 a backup/restore lies with the backup/restore application. =  The belief=20 is that most, if not all, that is needed is provided to allow this = to occur.=20  It would require the backup application to embed meta-data in = the data=20 stream backup up.  This would allow the restore application to = have=20 information necessary to regenerate the disk guard meta-data. =  However,=20 it is believed that something more is needed. 

If legacy commands are used then the = application tag=20 and reference tag are set to all 1's and the owner software should = know not=20 to check them.  However, if it doesn't do this the data will = become=20 unusable. 

The = belief was=20 expressed that for = backup it=20 would need to backup 520 bytes (512 bytes plus meta-data), preserve = the=20 application tag, and modify the ref tag on the restore depending on = LBA tag=20 locked or not, and regenerate the guard (CRC). 

There were a number of proposals = needed, of=20 which the following are what I captured. 
1) Need method to retrieve the = meta-data for=20 legacy devices. 
2) The CRC=20 needs to be seeded with 1's to allow for variable length blocks and = leading=20 0's (Rob was going to handle this one) 
3) Changes are needed for = Extended Copy=20 
4) For tape to extend = this concept=20 to tape, SSC-3 changes will be needed. (Kevin Butt will handle this = one in=20 the future) 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D 
Jim, 

I = think this=20 discussion about end-to-end and how it would affect backup/restore=20 operations needs to be discussed. 

First of all, variable length commands are not just a = potential.=20  They are reality.   Different block sizes are used = during typical=20 backups (e.g. the last block of a file is usually a different = length than=20 the rest, as well as headers and trailers).  Also, many ISVs = use=20 different block sizes.  We have customers who also use = overlength and=20 underlength transfers as a normal mode of operation. =  I'm=20 sure that has not been considered.  CRC must be seeded by 1's = to be=20 able to handle variable length blocks. 

Keep in mind, however, that the current data protection = proposals=20 ignore tape altogether.  In fact, the authors indicated that = they took=20 a look at Extended Copy and determined it was difficult to make = work and=20 they weren't interested in it so they decided to ignore it and let = anybody=20 interested in Extended Copy worry about it.  I have an action = from the=20 rest of the tapeheads to express our concerns and try to bring an=20 understanding to the tape world as well as to the disk world of how = this=20 data protection will effect backup/restore operations and how = backup/restore=20 operations will effect end-to-end data protection.  =20 

Included herein is a = summary of tape=20 issues and pieces of some of the conversations I've had with tape = (that's me=20 + the tape people present at the last ADI telecon), ISV people from = one ISV=20 (guess which one), and disk people. 

Assumptions: 
a) One of the=20 concerns was what happened when a disk crashed and a defrag = occurred and how=20 that effects LBA.  I've been informed that the defrag is = really a file=20 system issue and as such is an operating system concept that is = outside the=20 disk drive.  So this will have no bearing on LBA's. - Is this = also true=20 for RAID? 
b) = Backup/Restore software=20 currently does the equivalent of a meta-data transform today. =  The=20 software reads the data and the blocks to tape are different sizes = than=20 blocks read from disk.  To use disk block sizes would severely = degrade=20 performance. 
c) = Software today uses=20 two different types of operations for backup/restore.  They = are 1)=20 request a file from the OS, and 2) Image backup/restore where they = use the=20 actual LBA's.  These LBA's can be restored to different = locations than=20 from where they were read from.  Some examples are restoring = to a=20 different size disk than from which it was backed up, the OS = modifying its=20 filesystem. 

These = commands are=20 only SBC-2 and any talk of tape commands would need to be deferred = to=20 proposals to be brought in for inclusion in SSC-3 that would allow = tape to=20 play in the same arena.  The issue I am trying to focus on is = making=20 sure that a legacy backup/restore to tape 
1) can still occur (which I think it can with loss of = protection=20 across tape) and 
2) = that when a=20 legacy backup/restore to tape occurs that it doesn't break the = scheme such=20 that when the application client reads the data from the restored = disk with=20 the new data protection it doesn't cause the application client to = call the=20 data bad. 
3) that the = Extended Copy=20 command can still be used. 

Hopefully I can clear up some confusion.  I can = envision three=20 types of tape backup: 
<<  =3D=3D=3D> Is this section between = '<<' and=20 '>>' true? <=3D=3D=3D=3D 
All of my notes assume and RELY on: = 
1) The Application Tag = is=20 unused, 
2) The=20 Reference Tag (the one associated with the LBA) = is: Only = associated to=20 the LBA by the first Write command of a file.=20 Only = associated to=20 the LBA by the first Read command of a file.=20 The = application=20 client does not compare the Reference Tag of the Read command back = to the=20 Reference Tag of the Write command. 
During a backup/restore operation there is = potential=20 that the LBA's used on the Restore will be different from those = used on the=20 Backup.  Indeed, this is the crux of the concerns related to=20 interoperability issues with Tape or any other Backup/Restore = device.=20  If the Reference to the LBA is done in such a manner as to = tie the=20 data to the same LBA that was used on the initial Write, then this = will not=20 survive through a Backup/Restore operation. Indeed if any one of = the above=20 assumptions are not reality, then I see no guarantee that data = could survive=20 through a Backup/Restore operation. 
>> 

<<Mode 1 would nominally not have = protection to=20 tape.  However, proprietary data protection schemes that may = be=20 available from some tape vendors may be used to get a near = end-to-end data=20 protection but would be susceptible to the process that converted = the disk=20 protection scheme into the tape protection = scheme>>=20 
1. Mode 1 - where only the = block=20 data (typically 512 bytes) is written to and read from tape. =  The=20 software which reads and writes the disk has to know the disk block = size and=20 LBA, and can therefore check the CRC and Reference Tag  on = disk reads=20 and generate CRC and Tag on disk writes.  This is true as long = as the=20 Reference Tag Seed is the existing LBA in today's CDB.  This = is one=20 reason IBM does not want a new Reference Tag Seed in a new = 32 byte=20 CDB. 

The issue here = is the=20 Application Tag, which would be lost, but that is true for legacy = disk I/O=20 operations as well. 

<<Mode 2 would nominally not have protection to = tape.=20  However, proprietary data protection schemes that may be = available=20 from some tape vendors may be used to ensure a full end-to-end data = protection >>2. = Mode 2 - where=20 both the block data (typically 512 bytes) plus the eight check = bytes=20 is written to and read from tape.  The software (as with mode = 1) could=20 check the CRC and Tag on disk reads.  The data block plus = check bytes=20 could be written to and read from tape (as raw data).  The = disk=20 controller could check the CRC and Tag on the disk = writes. 

<<Mode 3 would have to wait for additions to = SSC-3 and may=20 need modifications to the concept listed>> 3. Mode 3 - where both the block data = (typically 512=20 bytes) plus the eight check bytes is written to and read from tape = plus=20 checked.  The software (as with mode 1) could check the = CRC and Tag=20 on disk reads.  The data block plus check bytes could be = written to and=20 read from tape (as with mode 2).  The disk controller (as with = mode 2)=20 could check the CRC and Tag on the disk writes. = 

In order for tape to check the CRC, tape = would need=20 to know the disk logical block size.  This would allow the SSC = streaming commands to be used to transfer multiple disk blocks as a = single=20 tape block and maintain a high data rate.  In order for tape = to check=20 the Tag, tape would need to know the disk LBA.  The software = which=20 reads and writes the disk has to know the disk LBA, but a new = mechanism=20 would be needed to pass this information to tape.  This would = be a very=20 complex operation of checking data in the middle of a block and I = believe=20 there would be resistance to this as well as possible technical=20 limitations. 

I = think the=20 software (or tape device driver) would need to create tape specific = guard=20 data around the tape block.  The user data, from the tape = perspective=20 would be the disk user data plus the disk meta-data.  I don't = know how=20 having multiple [data + CRC] sets would work in validating the tape = block=20 CRC since the value would go to zero several times throughout a = single=20 block.

Kevin D. Butt
Fibre Channel & SCSI Architect, = IBM Tape=20 Microcode, 
6TYA, 9000 S. Rita Rd., Tucson, AZ =  85744
Tie-line=20 321; Office: 520-799-5280, Lab: 799-5751, Fax: 799-4138, Email:=20 kdbutt at us.ibm.com 


------_=_NextPart_001_01C3A0C7.78A24759--




More information about the T10 mailing list