Quantcast

Problem reading variable block size tape

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problem reading variable block size tape

dec0077
Hi all,

I'm trying to set up a VTL to get rid of all the physical media my company has. The problem I'm having is this: my tapes are written on various systems and usually have variable length records.

I'm using a port of tcopy to copy them to mhVTL (I have version 1.5.2-275329b installed). I'm doing a few tests, for now using two VTLs and copying data from one to the other.

I found that I can read a tape if, just after loading it with mtx -f /dev/sg12 load 1 0, I set a block size on the tape drive that is bigger than the biggest record, for example with mt -f /dev/st0 setblk 131072

At this point, the situation is as follows:

[root@t4wst00001 ~]# mtx -f /dev/sg11 load 1 0
Loading media from Storage Element 1 into drive 0...done

[root@t4wst00001 ~]# mt -f /dev/st0 setblk 131072

[root@t4wst00001 ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 131072 bytes. Density code 0x51 (IBM 3592 J1A).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

[root@t4wst00001 ~]# ./tcopy /dev/st0
*** Written by Odin Explorer programmer
 tcopy: Tape File 1; Records: 1 to 2; Size: 4960
 tcopy: Tape File 1; Records: 3 to 21; Size: 120068
 tcopy: Tape File 1; Record:  22; Size 83124
 tcopy: Tape File 1; Records: 23 to 41; Size: 120068
 tcopy: Tape File 1; Record:  42; Size 83124
 tcopy: Tape File 1; Records: 43 to 61; Size: 120068
 tcopy: Tape File 1; Record:  62; Size 83124
 tcopy: Tape File 1; Records: 63 to 81; Size: 120068
 tcopy: Tape File 1; Record:  82; Size 83124
 tcopy: Tape File 1; Records: 83 to 101; Size: 120068
 tcopy: Tape File 1; Record:  102; Size 83124
 tcopy: Tape File 1; Records: 103 to 121; Size: 120068
 tcopy: Tape File 1; Record:  122; Size 83124
 tcopy: Tape File 1; Records: 123 to 141; Size: 120068
 tcopy: Tape File 1; Record:  142; Size 83124
 tcopy: Tape File 1; Records: 143 to 161; Size: 120068
 tcopy: Tape File 1; Record:  162; Size 83124
 tcopy: Tape File 1; Records: 163 to 178; Size: 9236
 tcopy: Tape File 1; Records: 179 to 180; Size: 99264
 tcopy: Tape File 1; Record  181; Size 66176
************************************************************
 tcopy: The end of tape is reached. Files on tape: 1

[root@t4wst00001 ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
 DR_OPEN IM_REP_EN

After the first read, even another setblk fails:

[root@t4wst00001 ~]# mt -f /dev/st0 setblk 131072
/dev/st0: No medium found

The only way to go back to a working state is to unload and reload the media.

I've checked the source of the port of tcopy I'm using (admittedly, my C skills are quite limited), and I don't see lines that reset the block size on the (virtual) tape drive.

Can someone help me solve this problem?

Thank you.

Best Regards,
Alberto M.


P.S. If it helps, I've attached the source of the tcopy I'm using.

tcopy.c
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem reading variable block size tape

Mark Harvey
Administrator
dec0077 wrote
Hi all,

I'm trying to set up a VTL to get rid of all the physical media my company has. The problem I'm having is this: my tapes are written on various systems and usually have variable length records.
Be careful.. The <large international company> hack left lots of damaged disk backups (including vtl).. Physical tape was OK.

dec0077 wrote
I'm using a port of tcopy to copy them to mhVTL (I have version 1.5.2-275329b installed). I'm doing a few tests, for now using two VTLs and copying data from one to the other.

I found that I can read a tape if, just after loading it with mtx -f /dev/sg12 load 1 0, I set a block size on the tape drive that is bigger than the biggest record, for example with mt -f /dev/st0 setblk 131072

At this point, the situation is as follows:

[root@t4wst00001 ~]# mtx -f /dev/sg11 load 1 0
Loading media from Storage Element 1 into drive 0...done

[root@t4wst00001 ~]# mt -f /dev/st0 setblk 131072

[root@t4wst00001 ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 131072 bytes. Density code 0x51 (IBM 3592 J1A).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

[root@t4wst00001 ~]# ./tcopy /dev/st0
*** Written by Odin Explorer programmer
 tcopy: Tape File 1; Records: 1 to 2; Size: 4960
 tcopy: Tape File 1; Records: 3 to 21; Size: 120068
 tcopy: Tape File 1; Record:  22; Size 83124
 tcopy: Tape File 1; Records: 23 to 41; Size: 120068
 tcopy: Tape File 1; Record:  42; Size 83124
 tcopy: Tape File 1; Records: 43 to 61; Size: 120068
 tcopy: Tape File 1; Record:  62; Size 83124
 tcopy: Tape File 1; Records: 63 to 81; Size: 120068
 tcopy: Tape File 1; Record:  82; Size 83124
 tcopy: Tape File 1; Records: 83 to 101; Size: 120068
 tcopy: Tape File 1; Record:  102; Size 83124
 tcopy: Tape File 1; Records: 103 to 121; Size: 120068
 tcopy: Tape File 1; Record:  122; Size 83124
 tcopy: Tape File 1; Records: 123 to 141; Size: 120068
 tcopy: Tape File 1; Record:  142; Size 83124
 tcopy: Tape File 1; Records: 143 to 161; Size: 120068
 tcopy: Tape File 1; Record:  162; Size 83124
 tcopy: Tape File 1; Records: 163 to 178; Size: 9236
 tcopy: Tape File 1; Records: 179 to 180; Size: 99264
 tcopy: Tape File 1; Record  181; Size 66176
************************************************************
 tcopy: The end of tape is reached. Files on tape: 1

[root@t4wst00001 ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
 DR_OPEN IM_REP_EN

After the first read, even another setblk fails:

[root@t4wst00001 ~]# mt -f /dev/st0 setblk 131072
/dev/st0: No medium found

The only way to go back to a working state is to unload and reload the media.

I've checked the source of the port of tcopy I'm using (admittedly, my C skills are quite limited), and I don't see lines that reset the block size on the (virtual) tape drive.

Can someone help me solve this problem?

Thank you.

Best Regards,
Alberto M.
Is there a reason your physically setting the target block size ?

Surely that's a job for your tape-copy utility. i.e. It should be setting the destination to match source (variable-block is much better for this sort of thing).

Can you post a copy of the syslog (typically /var/log/messages) which covers the timeframe of the above test ?
Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem reading variable block size tape

dec0077
Hello Mark,

Il 26/02/2015 00:24, Mark Harvey [via mhVTL - A Linux Virtual Tape Library] ha scritto:
dec0077 wrote
Hi all,

I'm trying to set up a VTL to get rid of all the physical media my company has. The problem I'm having is this: my tapes are written on various systems and usually have variable length records.
Be careful.. The <large international company> hack left lots of damaged disk backups (including vtl).. Physical tape was OK.


Thank you for the warning, but in this case the tapes are not used for backups, but for archiving of seismic data. The project I'm currently involved in aims to bring all data online and eliminate the physical media (we are talking about 3 PB of data on about 200k tapes).

dec0077 wrote
I'm using a port of tcopy to copy them to mhVTL (I have version 1.5.2-275329b installed). I'm doing a few tests, for now using two VTLs and copying data from one to the other.

I found that I can read a tape if, just after loading it with mtx -f /dev/sg12 load 1 0, I set a block size on the tape drive that is bigger than the biggest record, for example with mt -f /dev/st0 setblk 131072

At this point, the situation is as follows:

[root@t4wst00001 ~]# mtx -f /dev/sg11 load 1 0
Loading media from Storage Element 1 into drive 0...done

[root@t4wst00001 ~]# mt -f /dev/st0 setblk 131072

[root@t4wst00001 ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 131072 bytes. Density code 0x51 (IBM 3592 J1A).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

[root@t4wst00001 ~]# ./tcopy /dev/st0
*** Written by Odin Explorer programmer
 tcopy: Tape File 1; Records: 1 to 2; Size: 4960
 tcopy: Tape File 1; Records: 3 to 21; Size: 120068
 tcopy: Tape File 1; Record:  22; Size 83124
 tcopy: Tape File 1; Records: 23 to 41; Size: 120068
 tcopy: Tape File 1; Record:  42; Size 83124
 tcopy: Tape File 1; Records: 43 to 61; Size: 120068
 tcopy: Tape File 1; Record:  62; Size 83124
 tcopy: Tape File 1; Records: 63 to 81; Size: 120068
 tcopy: Tape File 1; Record:  82; Size 83124
 tcopy: Tape File 1; Records: 83 to 101; Size: 120068
 tcopy: Tape File 1; Record:  102; Size 83124
 tcopy: Tape File 1; Records: 103 to 121; Size: 120068
 tcopy: Tape File 1; Record:  122; Size 83124
 tcopy: Tape File 1; Records: 123 to 141; Size: 120068
 tcopy: Tape File 1; Record:  142; Size 83124
 tcopy: Tape File 1; Records: 143 to 161; Size: 120068
 tcopy: Tape File 1; Record:  162; Size 83124
 tcopy: Tape File 1; Records: 163 to 178; Size: 9236
 tcopy: Tape File 1; Records: 179 to 180; Size: 99264
 tcopy: Tape File 1; Record  181; Size 66176
************************************************************
 tcopy: The end of tape is reached. Files on tape: 1

[root@t4wst00001 ~]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (50000):
 DR_OPEN IM_REP_EN

After the first read, even another setblk fails:

[root@t4wst00001 ~]# mt -f /dev/st0 setblk 131072
/dev/st0: No medium found

The only way to go back to a working state is to unload and reload the media.

I've checked the source of the port of tcopy I'm using (admittedly, my C skills are quite limited), and I don't see lines that reset the block size on the (virtual) tape drive.

Can someone help me solve this problem?

Thank you.

Best Regards,
Alberto M.
Is there a reason your physically setting the target block size ?

Actually, I'm setting the block size on the source drive, otherwise I'm completely unable to read it. It would be easy to say the tcopy I'm using is faulty (and most likely it is), but I have the same problem with dd. The target tape drive is fine with a block size of 0... until I need to read it, that is: then I have to set a blocksize to be able to read it.


Surely that's a job for your tape-copy utility. i.e. It should be setting the destination to match source (variable-block is much better for this sort of thing).

I agree and, from what I can see, it's exactly what happens. Tcopy, historically, has had two main functions: the first (when specifying two tape names on the command line) is to copy the source to the destination. The other, with just one tape drive, outputs the map of the records on the tape; it's this second usage that my original mail showed.


Can you post a copy of the syslog (typically /var/log/messages) which covers the timeframe of the above test ?

Here it is... although at the moment I feel a bit silly... examining the /var/log/messages during the copy I just discovered that the tcopy port I'm using does a MTOFFL on the source tape and a MTWEOF/MTOFFL on the target tape at the end of the copy, which is not the normal behaviour, at least not the unloading of the tapes.

In any case:

Feb 26 08:59:08 mhvtl vtllibrary[1032]: CDB (129) (delay 223205): 12 00 00 00 38 00
Feb 26 08:59:08 mhvtl vtllibrary[1032]: spc_inquiry(): INQUIRY ** (129)
Feb 26 08:59:08 mhvtl vtllibrary[1032]: CDB (130) (delay 405): 1a 08 1d 00 88 00
Feb 26 08:59:08 mhvtl vtllibrary[1032]: spc_mode_sense(): MODE SENSE 6 (130) **
Feb 26 08:59:08 mhvtl vtllibrary[1032]: CDB (131) (delay 405): b8 12 04 00 00 19 00 00 0c f4 00 00
Feb 26 08:59:08 mhvtl vtllibrary[1032]: smc_read_element_status(): READ ELEMENT STATUS (131) **
Feb 26 08:59:08 mhvtl vtllibrary[1032]: CDB (132) (delay 405): b8 13 03 00 00 08 00 00 0c f4 00 00
Feb 26 08:59:08 mhvtl vtllibrary[1032]: smc_read_element_status(): READ ELEMENT STATUS (132) **
Feb 26 08:59:08 mhvtl vtllibrary[1032]: CDB (133) (delay 405): b8 14 00 01 00 05 00 00 0c f4 00 00
Feb 26 08:59:08 mhvtl vtllibrary[1032]: smc_read_element_status(): READ ELEMENT STATUS (133) **
Feb 26 08:59:08 mhvtl vtllibrary[1032]: CDB (134) (delay 405): b8 11 02 f0 00 01 00 00 0c f4 00 00
Feb 26 08:59:08 mhvtl vtllibrary[1032]: smc_read_element_status(): READ ELEMENT STATUS (134) **
Feb 26 08:59:08 mhvtl vtllibrary[1032]: CDB (135) (delay 405): a5 00 02 f0 04 00 00 01 00 00 00 00
Feb 26 08:59:08 mhvtl vtllibrary[1032]: smc_move_medium(): MOVE MEDIUM (135) **
Feb 26 08:59:08 mhvtl vtllibrary[1032]: smc_move_medium(): Moving from slot 1024 to slot 1 using transport 752, Invert media: no
Feb 26 08:59:08 mhvtl vtllibrary[1032]: move_slot2drive(): About to send cmd: 'lload M00001L1' to drive 1
Feb 26 08:59:08 mhvtl vtltape[957]: processMessageQ(): Sender id: 90, msg : lload M00001L1
Feb 26 08:59:08 mhvtl vtltape[957]: loadTape(): Media type 'LTO1' loaded with S/No. : M00001L1_1418808588
Feb 26 08:59:08 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [06 28 00]
Feb 26 08:59:08 mhvtl vtltape[957]: loadTape(): Media is writable
Feb 26 08:59:08 mhvtl vtltape[957]: loadTape(): Setting MediumDensityCode to LTO1 (0x40) Media type: 0x18
Feb 26 08:59:14 mhvtl vtllibrary[1035]: CDB (136) (delay 232805): 12 00 00 00 38 00
Feb 26 08:59:14 mhvtl vtllibrary[1035]: spc_inquiry(): INQUIRY ** (136)
Feb 26 08:59:14 mhvtl vtllibrary[1035]: CDB (137) (delay 405): 1a 08 1d 00 88 00
Feb 26 08:59:14 mhvtl vtllibrary[1035]: spc_mode_sense(): MODE SENSE 6 (137) **
Feb 26 08:59:14 mhvtl vtllibrary[1035]: CDB (138) (delay 405): b8 12 04 00 00 19 00 00 0b f8 00 00
Feb 26 08:59:14 mhvtl vtllibrary[1035]: smc_read_element_status(): READ ELEMENT STATUS (138) **
Feb 26 08:59:14 mhvtl vtllibrary[1035]: CDB (139) (delay 405): b8 13 03 00 00 05 00 00 0b f8 00 00
Feb 26 08:59:14 mhvtl vtllibrary[1035]: smc_read_element_status(): READ ELEMENT STATUS (139) **
Feb 26 08:59:14 mhvtl vtllibrary[1035]: CDB (140) (delay 405): b8 14 00 01 00 05 00 00 0b f8 00 00
Feb 26 08:59:14 mhvtl vtllibrary[1035]: smc_read_element_status(): READ ELEMENT STATUS (140) **
Feb 26 08:59:14 mhvtl vtllibrary[1035]: CDB (141) (delay 405): b8 11 02 f0 00 01 00 00 0b f8 00 00
Feb 26 08:59:14 mhvtl vtllibrary[1035]: smc_read_element_status(): READ ELEMENT STATUS (141) **
Feb 26 08:59:14 mhvtl vtllibrary[1035]: CDB (142) (delay 405): a5 00 02 f0 04 00 00 01 00 00 00 00
Feb 26 08:59:14 mhvtl vtllibrary[1035]: smc_move_medium(): MOVE MEDIUM (142) **
Feb 26 08:59:14 mhvtl vtllibrary[1035]: smc_move_medium(): Moving from slot 1024 to slot 1 using transport 752, Invert media: no
Feb 26 08:59:14 mhvtl vtllibrary[1035]: move_slot2drive(): About to send cmd: 'lload M00001JA' to drive 1
Feb 26 08:59:14 mhvtl vtltape[976]: processMessageQ(): Sender id: 110, msg : lload M00001JA
Feb 26 08:59:14 mhvtl vtltape[976]: loadTape(): Media type '03592 JA' loaded with S/No. : M00001JA_1424871147
Feb 26 08:59:14 mhvtl vtltape[976]: return_sense(): [Key/ASC/ASCQ] [06 28 00]
Feb 26 08:59:14 mhvtl vtltape[976]: loadTape(): Media is writable
Feb 26 08:59:14 mhvtl vtltape[976]: loadTape(): Setting MediumDensityCode to 03592 JA (0x51) Media type: 0x00
Feb 26 08:59:47 mhvtl vtltape[976]: CDB (143) (delay 287205): 00 00 00 00 00 00
Feb 26 08:59:47 mhvtl vtltape[976]: return_sense(): [Key/ASC/ASCQ] [06 29 00]
Feb 26 08:59:47 mhvtl vtltape[976]: CDB (144) (delay 405): 00 00 00 00 00 00
Feb 26 08:59:47 mhvtl vtltape[976]: ssc_tur(): Test Unit Ready (144) ** : Yes
Feb 26 08:59:47 mhvtl vtltape[976]: CDB (145) (delay 405): 05 00 00 00 00 00
Feb 26 08:59:47 mhvtl vtltape[976]: ssc_read_block_limits(): READ BLOCK LIMITS (145) **
Feb 26 08:59:47 mhvtl kernel: st5: Block limits 4 - 2097152 bytes.
Feb 26 08:59:47 mhvtl vtltape[976]: CDB (146) (delay 805): 1a 00 00 00 0c 00
Feb 26 08:59:47 mhvtl vtltape[976]: spc_mode_sense(): MODE SENSE 6 (146) **
Feb 26 08:59:47 mhvtl vtltape[976]: CDB (147) (delay 405): 15 10 00 00 0c 00
Feb 26 08:59:47 mhvtl vtltape[976]: ssc_mode_select(): MODE SELECT 6 (147) **
Feb 26 08:59:47 mhvtl vtltape[976]: ssc_mode_select():  Save Pages: 0, Page Format conforms to T10 standard
Feb 26 08:59:47 mhvtl vtltape[957]: CDB (148) (delay 287205): 00 00 00 00 00 00
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [06 29 00]
Feb 26 08:59:47 mhvtl vtltape[957]: CDB (149) (delay 405): 00 00 00 00 00 00
Feb 26 08:59:47 mhvtl vtltape[957]: ssc_tur(): Test Unit Ready (149) ** : Yes
Feb 26 08:59:47 mhvtl vtltape[957]: CDB (150) (delay 405): 05 00 00 00 00 00
Feb 26 08:59:47 mhvtl vtltape[957]: ssc_read_block_limits(): READ BLOCK LIMITS (150) **
Feb 26 08:59:47 mhvtl kernel: st0: Block limits 4 - 2097152 bytes.
Feb 26 08:59:47 mhvtl vtltape[957]: CDB (151) (delay 805): 1a 00 00 00 0c 00
Feb 26 08:59:47 mhvtl vtltape[957]: spc_mode_sense(): MODE SENSE 6 (151) **
Feb 26 08:59:47 mhvtl vtltape[957]: CDB (152) (delay 805): 15 10 00 00 0c 00
Feb 26 08:59:47 mhvtl vtltape[957]: ssc_mode_select(): MODE SELECT 6 (152) **
Feb 26 08:59:47 mhvtl vtltape[957]: ssc_mode_select():  Save Pages: 0, Page Format conforms to T10 standard
Feb 26 08:59:47 mhvtl vtltape[957]: CDB (153) (delay 405): 08 00 09 27 c0 00
Feb 26 08:59:47 mhvtl vtltape[957]: rw_6(): READ: 1 block of 600000 bytes (153) **
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[976]: CDB (154) (delay 7205): 0a 00 00 13 60 00
Feb 26 08:59:47 mhvtl vtltape[976]: rw_6(): WRITE: 1 block of 4960 bytes (154) **
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: processCommand(): 50th contiguous READ_6 request (253) (delay 53050)
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[976]: processCommand(): 50th contiguous WRITE_6 request (254) (delay 35450)
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:47 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: processCommand(): 100th contiguous READ_6 request (353) (delay 43050)
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[976]: processCommand(): 100th contiguous WRITE_6 request (354) (delay 26250)
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: processCommand(): 150th contiguous READ_6 request (453) (delay 54250)
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[976]: processCommand(): 150th contiguous WRITE_6 request (454) (delay 36250)
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [20 00 00]
Feb 26 08:59:48 mhvtl vtltape[957]: readBlock(): Expected to find DATA header, found: FILEMARK
Feb 26 08:59:48 mhvtl vtltape[957]: position_blocks_forw(): Filemark encountered: block 181
Feb 26 08:59:48 mhvtl vtltape[957]: return_sense(): [Key/ASC/ASCQ] [80 00 01]
Feb 26 08:59:48 mhvtl rsyslogd-2177: imuxsock begins to drop messages from pid 957 due to rate-limiting
Feb 26 08:59:48 mhvtl vtltape[976]: CDB (516) (delay 805): 10 00 00 00 01 00
Feb 26 08:59:48 mhvtl vtltape[976]: ssc_write_filemarks(): WRITE 1 FILEMARKS (516) **
Feb 26 08:59:48 mhvtl vtltape[976]: CDB (519) (delay 4005): 10 00 00 00 01 00
Feb 26 08:59:48 mhvtl vtltape[976]: ssc_write_filemarks(): WRITE 1 FILEMARKS (519) **
Feb 26 08:59:49 mhvtl vtltape[976]: CDB (520) (delay 5): 1b 00 00 00 00 00
Feb 26 08:59:49 mhvtl vtltape[976]: ssc_load_unload(): UNLOADING TAPE (520) **


Thank you for your support and apologies if I'm making you waste time.


Best Regards,
Alberto M.


Regards from Australia
Mark Harvey



To unsubscribe from Problem reading variable block size tape, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem reading variable block size tape

Mark Harvey
Administrator
Hmmm..

I used the tcopy provided above & reformatted to suit the 'linux kernel' coding style.. I also added some comments as I worked my way thru the code..
Also changed to use more generic (portable) include files.. Some of the include files were very specific.

tcopy_mhvtl.c (renamed to help with naming conflicts).

This was able to successfully 'tcopy' a NetBackup tape without any real problem - although a minor difference between source & destination is the additional file mark at the end of the tape.

The setting of the 128k block size before running the tcopy should make no difference as the first thing tcopy does is set the block size to '0' (variable).

Do you know what the license is for the tcopy.c you posted ?
If applicable, I'd like to include this with the mhvtl distribution.. Just needs some work from a usability & robustness point of view.
Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem reading variable block size tape

dec0077
Hello Mark,


wow, you even took the time to clean up the code! Well, tcopy is quite useful and standard issue on Solaris machines, while there is no official ports on linux. I'm sorry, but I know nothing else about the tcopy source... aside from the mention of "*** Written by Odin Explorer programmer" into the code there seems to be no other indication as to the author.

At the moment I'm using my home PC, but I originally downloaded the tcopy.c file from my  work notebook... If the browsing history is still there I can try to find the page I found it on. Maybe there'll be some hints on how to contact the coder.

Thank you for your support and your time.


Best Regards,
Alberto M.


Il 02/03/2015 01:10, Mark Harvey [via mhVTL - A Linux Virtual Tape Library] ha scritto:
Hmmm..

I used the tcopy provided above & reformatted to suit the 'linux kernel' coding style.. I also added some comments as I worked my way thru the code..
Also changed to use more generic (portable) include files.. Some of the include files were very specific.

tcopy_mhvtl.c (renamed to help with naming conflicts).

This was able to successfully 'tcopy' a NetBackup tape without any real problem - although a minor difference between source & destination is the additional file mark at the end of the tape.

The setting of the 128k block size before running the tcopy should make no difference as the first thing tcopy does is set the block size to '0' (variable).

Do you know what the license is for the tcopy.c you posted ?
If applicable, I'd like to include this with the mhvtl distribution.. Just needs some work from a usability & robustness point of view.
Regards from Australia
Mark Harvey



To unsubscribe from Problem reading variable block size tape, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem reading variable block size tape

Mark Harvey
Administrator
A little more searching and I've found a couple of versions (on sourceforge) of the original tcopy.c you posted. One tar ball with CVS history even :)

Apart from the 'eject source and target tape on completion' surprise - this tcopy should do the job for you.

Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem reading variable block size tape

dec0077
Hello Mark,


yes, I found them as well and did try to use them, but had problems that the version I attached to my original message did not have... I think I'll have to check those again.

I'll keep you posted.


Thanks,
Alberto M.



      
Il 02/03/2015 04:20, Mark Harvey [via mhVTL - A Linux Virtual Tape Library] ha scritto:
A little more searching and I've found a couple of versions (on sourceforge) of the original tcopy.c you posted. One tar ball with CVS history even :)

Apart from the 'eject source and target tape on completion' surprise - this tcopy should do the job for you.

Regards from Australia
Mark Harvey



To unsubscribe from Problem reading variable block size tape, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem reading variable block size tape

dec0077
In reply to this post by Mark Harvey
In any case, this is where I got the copy of tcopy.c from:

http://lists.gnu.org/archive/html/bug-gnu-utils/2002-06/msg00308.html


Best Regards,
Alberto M.



Il 02/03/2015 09:13, Alberto Mariani ha scritto:
Hello Mark,


yes, I found them as well and did try to use them, but had problems that the version I attached to my original message did not have... I think I'll have to check those again.

I'll keep you posted.


Thanks,
Alberto M.


Il 02/03/2015 04:20, Mark Harvey [via mhVTL - A Linux Virtual Tape Library] ha scritto:
A little more searching and I've found a couple of versions (on sourceforge) of the original tcopy.c you posted. One tar ball with CVS history even :)

Apart from the 'eject source and target tape on completion' surprise - this tcopy should do the job for you.

Regards from Australia
Mark Harvey



To unsubscribe from Problem reading variable block size tape, click here.
NAML


Loading...