apparent blocksize shift error when tape is copied to MHVTL then read back from MHVTL tape

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: apparent blocksize shift error when tape is copied to MHVTL then read back from MHVTL tape

dlsk
That helped to explain it, the virtual tape ran out of space after consuming 524288000 bytes. I learned that  the LTO "L2,L3" size when a virtual tape is created is enforced and this makes sense. Previously I ignored this (using any convenient name -- just like we do for the Sepaton)  and regardless of suffix (type) I found I could store any size data I was copying.  Now I'll simply make them all L3 or L4 to accommodate the range of sizes I usually see. I think that should do it. I'll start serious use of the most recent version immediately.

Thanks for all your help....

[root@orinoco ~]# head FS00008L2.dump
PCL is : FS0008L2
Media density code: 0x58
Media type code   : 0x03
Media description : Ultrium 2/8T
Tape Capacity     : 524288000
Total num of filemarks: 1
Hdr:   Compressed data(0b), sz     20/80    , Blk No.: 0, data 0
Hdr:   Compressed data(0b), sz     53/80    , Blk No.: 1, data 20
Hdr:   Compressed data(0b), sz     27/80    , Blk No.: 2, data 73
Hdr:   Compressed data(0b), sz     22/80    , Blk No.: 3, data 100
[root@orinoco ~]# head FS0008L3.dump
PCL is : FS0008L3
Media density code: 0x58
Media type code   : 0x05
Media description : Ultrium 3/16T
Tape Capacity     : 209715200000
Total num of filemarks: 3
Hdr:   Compressed data(0b), sz     20/80    , Blk No.: 0, data 0
Hdr:   Compressed data(0b), sz     53/80    , Blk No.: 1, data 20
Hdr:   Compressed data(0b), sz     27/80    , Blk No.: 2, data 73
Hdr:   Compressed data(0b), sz     22/80    , Blk No.: 3, data 100
Reply | Threaded
Open this post in threaded view
|

Re: apparent blocksize shift error when tape is copied to MHVTL then read back from MHVTL tape

dlsk
Strange: Changed the Library from " Vendor identification: STK & Product identification: L700" to
"Vendor identification: SPECTRA & Product identification: PYTHON". Then re-created tape image FS0008L2.
Now getting 209 Gig capacity rather than 542 Meg:

Then changed these options back to where they were originally. Deleted image then recreated and size remains fine. Not sure why I was getting the 522 Meg size limitation before... But it looks like I can now keep my old naming convention.

[root@orinoco mhvtl]# dump_tape -f FS0008L2 | head
PCL is : FS0008L2
Media density code: 0x42
Media type code   : 0x03
Media description : Ultrium 2/8T
Tape Capacity     : 209715200000
Total num of filemarks: 0
Reply | Threaded
Open this post in threaded view
|

Re: apparent blocksize shift error when tape is copied to MHVTL then read back from MHVTL tape

dlsk
Reboot seems to have cleared it up for good and all newly created tapes no longer get the default 500 Meg size. By the way all my "default capacity" is/was set to:

# Default media capacity (500 M)
CAPACITY=200000
Reply | Threaded
Open this post in threaded view
|

Re: apparent blocksize shift error when tape is copied to MHVTL then read back from MHVTL tape

dlsk
Reverted to release 18-5 after application failures when reading  MHVTL in release 18-13 tapes.
Local tool indicates mhvtl tape (on readback)  is identical to original sepaton tape
dump_tape produces same output for tape used on version 18-5 and version 18-13beta2

**Application log FAILURE case ON Orinoco: MHVTL version 18-13 beta2:***

2011/01/12 11:07:05 notice: TAPE catalog /dev/nst0 (/dev/nst0): 2 backupsets found in tapedb for dbid 6, 15 backupsets stored, 17 backupset extents stored, 17 catok
2011/01/12 11:07:05 notice: TAPE catalog /dev/nst0 (/dev/nst0): go to compute tailsig
/dev/nst0 [20110112 11:07:05.552]: <<<<<< <<<<<< locate to 79097
/dev/nst0 [20110112 11:07:05.555]: initial locate_threshold to 15000 @ 79097
/dev/nst0 [20110112 11:07:05.563]: rec 65536 (10000)
/dev/nst0 [20110112 11:07:05.599]: 8 blocks, <UNK> bytes @ 79105
/dev/nst0 [20110112 11:07:05.602]: eof 18
/dev/nst0 [20110112 11:07:05.604]: rec 65536 (10000) @ 79106
/dev/nst0 [20110112 11:07:05.606]: 1 block, 65,536 bytes @ 79107
/dev/nst0 [20110112 11:07:05.608]: throughput = 9.8 MB/s
/dev/nst0 [20110112 11:07:05.608]: blank check
2011/01/12 11:07:05 notice: TAPE catalog /dev/nst0 (/dev/nst0): go to compute headsig
/dev/nst0 [20110112 11:07:05.608]: total 28 blocks, 1,835,008 bytes, 19 skips
/dev/nst0 [20110112 11:07:05.608]: <<<<<< <<<<<< rewind
/dev/nst0 [20110112 11:07:05.611]: rec 65536 (10000) @ 0
/dev/nst0 [20110112 11:07:05.612]: 1 block, 65,536 bytes @ 1
/dev/nst0 [20110112 11:07:05.613]: throughput = 18.1 MB/s
/dev/nst0 [20110112 11:07:05.613]: eof 1
/dev/nst0 [20110112 11:07:05.614]: rec 65536 (10000) @ 2
/dev/nst0 [20110112 11:07:05.626]: >>>>>> >>>>>> skipping to the end @ 10
/dev/nst0 [20110112 11:07:05.628]: mismatch, eod found at 10 but expected later @ 14756
2011/01/12 11:07:05 error: TAPE catalog /dev/nst0 (/dev/nst0): error -9 jumping to EOD
2011/01/12 11:07:05 warning: TAPE catalog /dev/nst0 (/dev/nst0): unknown loc starting at 4294967295 after seek on [tapedbid="6", voltag="N29630L2", label="E104-002-10/17/08 2:31 PM"]
2011/01/12 11:07:05 notice: ratemon: 0.000000 tape rate (final)
2011/01/12 11:07:05 notice: TAPE catalog /dev/nst0 (/dev/nst0): not saving tapeblocks info because of medium errors on [tapedbid="6", voltag="N29630L2", label="E104-002-10/17/08 2:31 PM"]
2011/01/12 11:07:05 notice: TAPE catalog /dev/nst0 (/dev/nst0): end cat [tapedbid="6", voltag="N29630L2", label="E104-002-10/17/08 2:31 PM"] (rerrors=0, ierrors=0, eot=0, supp=1, status=failed)

*** APPLICATION LOG SUCCESS FOR SAME TAPE on MHVTL Version 18-5 *******
********* SUCCESS WITH N29630 on ORINOCO  Version 18-5 *****************
2011/01/12 16:08:45 notice: TAPE catalog /dev/nst0 (/dev/nst0): go to compute tailsig
/dev/nst0 [20110112 16:08:45.279]: <<<<<< <<<<<< locate to 79097
/dev/nst0 [20110112 16:08:45.298]: initial locate_threshold to 15000 @ 79097
/dev/nst0 [20110112 16:08:45.311]: rec 65536 (10000)
/dev/nst0 [20110112 16:08:45.339]: 8 blocks, <UNK> bytes @ 79105
/dev/nst0 [20110112 16:08:45.339]: eof 18
/dev/nst0 [20110112 16:08:45.341]: rec 65536 (10000) @ 79106
/dev/nst0 [20110112 16:08:45.342]: 1 block, 65,536 bytes @ 79107
/dev/nst0 [20110112 16:08:45.344]: throughput = 14.6 MB/s
/dev/nst0 [20110112 16:08:45.344]: blank check
2011/01/12 16:08:45 notice: TAPE catalog /dev/nst0 (/dev/nst0): go to compute headsig
/dev/nst0 [20110112 16:08:45.344]: total 28 blocks, 1,835,008 bytes, 19 skips
/dev/nst0 [20110112 16:08:45.344]: <<<<<< <<<<<< rewind
/dev/nst0 [20110112 16:08:45.344]: rec 65536 (10000) @ 0
/dev/nst0 [20110112 16:08:45.345]: 1 block, 65,536 bytes @ 1
/dev/nst0 [20110112 16:08:45.347]: throughput = 19.1 MB/s
/dev/nst0 [20110112 16:08:45.347]: eof 1
/dev/nst0 [20110112 16:08:45.349]: rec 65536 (10000) @ 2
/dev/nst0 [20110112 16:08:45.353]: >>>>>> >>>>>> skipping to the end @ 10
/dev/nst0 [20110112 16:08:45.353]: 79105 blocks, <UNK> bytes @ 79107
/dev/nst0 [20110112 16:08:45.353]: blank check
2011/01/12 16:08:45 notice: ratemon: 0.000000 tape rate (final)
tdbSaveTapemap, tapeid = 1
==============================================================================
Snippet of MHVTL LOG from failure with Version 18-13 beta2

ORINOCO 11:07:05 Failure with 18-13beta2

Jan 12 11:07:05 orinoco vtltape[2966]: setTapeAlert: Setting TapeAlert flags 0x00000000 00000000
Jan 12 11:07:05 orinoco vtltape[2966]: completeSCSICommand: OP s/n: (1216), sz: 324, sam_status: 0
Jan 12 11:07:05 orinoco vtltape[2966]: CDB (1217) 08 00 01 00 00 00
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: READ_6 (1217) : 65536 bytes **
Jan 12 11:07:05 orinoco vtltape[2966]: readBlock: Request to read: 65536 bytes, SILI: 0
Jan 12 11:07:05 orinoco vtltape[2966]: read_tape_block: Reading blk 79106
Jan 12 11:07:05 orinoco vtltape[2966]: read_header: Reading header 79107 at offset 2875229928, type: END OF DATA
Jan 12 11:07:05 orinoco vtltape[2966]: readBlock: Read 460 (460) bytes of compressed data, have 65536 bytes for result
Jan 12 11:07:05 orinoco vtltape[2966]: completeSCSICommand: OP s/n: (1217), sz: 65536, sam_status: 0
Jan 12 11:07:05 orinoco vtltape[2966]: CDB (1218) 11 01 00 00 01 00
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: SPACE (1218) ** forward 1 filemark
Jan 12 11:07:05 orinoco vtltape[2966]: read_header: Reading header 79107 at offset 2875229928, type: END OF DATA
Jan 12 11:07:05 orinoco vtltape[2966]: mkSenseBuf: Sense buf: 0x617f80
Jan 12 11:07:05 orinoco vtltape[2966]: mkSenseBuf: SENSE [Key/ASC/ASCQ] [08 00 05]
Jan 12 11:07:05 orinoco vtltape[2966]: completeSCSICommand: OP s/n: (1218), sz: 0, sam_status: 2
Jan 12 11:07:05 orinoco vtltape[2966]: completeSCSICommand: [Key/ASC/ASCQ] [08 00 05]
Jan 12 11:07:05 orinoco vtltape[2966]: CDB (1219) 34 00 00 00 00 00 00 00 00 00
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: Read Position (1219) **
Jan 12 11:07:05 orinoco vtltape[2966]: resp_read_position: Positioned at block 79107
Jan 12 11:07:05 orinoco vtltape[2966]: completeSCSICommand: OP s/n: (1219), sz: 20, sam_status: 0
Jan 12 11:07:05 orinoco vtltape[2966]: CDB (1220) 4d 00 43 00 00 00 00 00 58 00
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: LOG SENSE (1220) **
Jan 12 11:07:05 orinoco vtltape[2966]: resp_log_sense: LOG SENSE: Read error page
Jan 12 11:07:05 orinoco vtltape[2966]: completeSCSICommand: OP s/n: (1220), sz: 88, sam_status: 0
Jan 12 11:07:05 orinoco vtltape[2966]: CDB (1221) 4d 00 6e 00 00 00 00 01 44 00
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: LOG SENSE (1221) **
Jan 12 11:07:05 orinoco vtltape[2966]: resp_log_sense: LOG SENSE: TapeAlert page
Jan 12 11:07:05 orinoco vtltape[2966]: resp_log_sense:  Returning TapeAlert flags: 0x0
Jan 12 11:07:05 orinoco vtltape[2966]: setTapeAlert: Setting TapeAlert flags 0x00000000 00000000
Jan 12 11:07:05 orinoco vtltape[2966]: completeSCSICommand: OP s/n: (1221), sz: 324, sam_status: 0
Jan 12 11:07:05 orinoco vtltape[2966]: CDB (1222) 2b 00 00 00 01 35 03 00 00 00
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: Fast Block Locate (1222) **
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: Current blk: 79107, seek: 79107
Jan 12 11:07:05 orinoco vtltape[2966]: position_to_block: Position to block 79107
Jan 12 11:07:05 orinoco vtltape[2966]: read_header: Reading header 79107 at offset 2875229928, type: END OF DATA
Jan 12 11:07:05 orinoco vtltape[2966]: completeSCSICommand: OP s/n: (1222), sz: 0, sam_status: 0
Jan 12 11:07:05 orinoco vtltape[2966]: CDB (1223) 2b 00 00 00 01 34 f9 00 00 00
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: Fast Block Locate (1223) **
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: Current blk: 79107, seek: 79097
Jan 12 11:07:05 orinoco vtltape[2966]: position_to_block: Position to block 79097
Jan 12 11:07:05 orinoco vtltape[2966]: read_header: Reading header 79097 at offset 2874704972, type: DATA
Jan 12 11:07:05 orinoco vtltape[2966]: completeSCSICommand: OP s/n: (1223), sz: 0, sam_status: 0
Jan 12 11:07:05 orinoco vtltape[2966]: CDB (1224) 08 00 01 00 00 00
Jan 12 11:07:05 orinoco vtltape[2966]: processCommand: READ_6 (1224) : 65536 bytes **
Jan 12 11:07:05 orinoco vtltape[2966]: readBlock: Request to read: 65536 bytes, SILI: 0
Jan 12 11:07:05 orinoco vtltape[2966]: read_tape_block: Reading blk 79097


Reply | Threaded
Open this post in threaded view
|

Re: apparent blocksize shift error when tape is copied to MHVTL then read back from MHVTL tape

Mark Harvey
Administrator
Thanks for the update.

Although I'm a little unclear as to the actual problem. I need to spend some time reviewing the information you posted :)

If you are going to use the 18-5 release, can I please ask you to apply this patch first.
It fixes a bug where a 'SPACE 0 Blocks/filemarks' will actually cause a reposition to the incorrect location.

FWIW: Most applications do not send a 'SPACE 0 blocks or filemarks'. It's used to force a flush of data from buffers to tape.

0001-SPACE-Test-for-zero-before-attempting-to-reposition.patch

Cheers
Mark
Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|

Re: apparent blocksize shift error when tape is copied to MHVTL then read back from MHVTL tape

Mark Harvey
Administrator
In reply to this post by dlsk
Do you have the syslog from the 0.18-13Beta2 tests ?

2011/01/12 11:07:05 notice: TAPE catalog /dev/nst0 (/dev/nst0): go to compute headsig
/dev/nst0 [20110112 11:07:05.608]: total 28 blocks, 1,835,008 bytes, 19 skips
/dev/nst0 [20110112 11:07:05.608]: <<<<<< <<<<<< rewind
/dev/nst0 [20110112 11:07:05.611]: rec 65536 (10000) @ 0
/dev/nst0 [20110112 11:07:05.612]: 1 block, 65,536 bytes @ 1
/dev/nst0 [20110112 11:07:05.613]: throughput = 18.1 MB/s
/dev/nst0 [20110112 11:07:05.613]: eof 1
/dev/nst0 [20110112 11:07:05.614]: rec 65536 (10000) @ 2
/dev/nst0 [20110112 11:07:05.626]: >>>>>> >>>>>> skipping to the end @ 10
/dev/nst0 [20110112 11:07:05.628]: mismatch, eod found at 10 but expected later @ 14756

I'd like to see what is being sent and how I'm processing it. :)
Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|

Re: apparent blocksize shift error when tape is copied to MHVTL then read back from MHVTL tape

dlsk
I've compressed the log N29630L2_18-13beta2.syslog.gz using "gzip N29630L2_18-13beta2.syslog" and  uploaded it...
12