sciuriware
asked on
DLT tape gives only half blocks back of what was written.
Some 11 Tb was dumped for me on 330 DLT tapes using a blocksize of 512Kb.
When I read those tapes on a HP target machine I get only the 1st half of every block.
Funny that it doesn't matter if I use dd with bs=256k or bs=512k, the result is the same:
the first 256Kb of every block. Even a JAVA 1.4 program using RandomAccessFile to byte[512*1024]
produces the same result.
I presume that the original writing program (in C) wrote some SCSI commands to the drive
in order to get it to write (and read) 512 Kb blocks.
Who knows how to archieve the reading of all 35Gb per tape?
;JOOP!
When I read those tapes on a HP target machine I get only the 1st half of every block.
Funny that it doesn't matter if I use dd with bs=256k or bs=512k, the result is the same:
the first 256Kb of every block. Even a JAVA 1.4 program using RandomAccessFile to byte[512*1024]
produces the same result.
I presume that the original writing program (in C) wrote some SCSI commands to the drive
in order to get it to write (and read) 512 Kb blocks.
Who knows how to archieve the reading of all 35Gb per tape?
;JOOP!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
For HP UX 11 dd the input default block size is 512 so I would think that it should not be necessary to use bs=.
I guess you could try using ibs= any ways to specify an input block size of 512, but...
Perhaps tcio will help, from the HP UX man.
"You may experience trouble writing directly to or reading directly from a cartridge tape. For best results, use tcio(1) as an input or output filter. For example for input from a cartridge tape, use
tcio -ivS 256 /dev/rct/c4t1d0 | dd ... | ..."
I guess you could try using ibs= any ways to specify an input block size of 512, but...
Perhaps tcio will help, from the HP UX man.
"You may experience trouble writing directly to or reading directly from a cartridge tape. For best results, use tcio(1) as an input or output filter. For example for input from a cartridge tape, use
tcio -ivS 256 /dev/rct/c4t1d0 | dd ... | ..."
ASKER
You still don't get it:
1) the default blocksize of dd is 512 bytes and that has been so for 34 years ....
2) it is the drive that delivers 256Kb for each block of 512Kb requested.
;JOOP!
1) the default blocksize of dd is 512 bytes and that has been so for 34 years ....
2) it is the drive that delivers 256Kb for each block of 512Kb requested.
;JOOP!
ASKER
You don't know how to perform a SCSI command based on the above parameters?
;JOOP!
;JOOP!
The machine that wrote the tape, or the drive attached to that machine, was probably faulty. Are you really getting only 256Kb or are you getting 512kb with 256kb of nulls?
ASKER
Please READ the details in my question.
I can see that the software package that writes (and re-reads) the tapes performs SCSI commands.
And all those 11.5 Terabytes are there!
;JOOP!
I can see that the software package that writes (and re-reads) the tapes performs SCSI commands.
And all those 11.5 Terabytes are there!
;JOOP!
Are you saying the tape has physical blocks 512K long? That sounds mighty unlikely. When I was working with SCSI tapes block sizes were MUCH smaller than that.
You may have to go back to the original writer of the tape and ask exactly how the tape was written. It may even require a special tape drive with special firmware.
You may have to go back to the original writer of the tape and ask exactly how the tape was written. It may even require a special tape drive with special firmware.
ASKER
No no no!
The tapes are read and written with a special program (in C) 6 years old.
And DLT-7000 has a maximum blocksize of 16M.
Please do not comment if you don't know about that.
;JOOP!
The tapes are read and written with a special program (in C) 6 years old.
And DLT-7000 has a maximum blocksize of 16M.
Please do not comment if you don't know about that.
;JOOP!
Post the source code of the backup program.
Ok, here's one possibility: some tape driver hardware requires a contiguous buffer space as long as the block size, other tape hardware can make do with a linked list of non-sequential memory areas. This space has to not only be one unbroken area, but it has to be allocated from the system or kernel heap. Unfortunately some kernels either cannot allocate or do not have one unbroken stretch of kernel memory large enough.
You may want to look into increasing the kernel heap by a few megabytes, or see if there's some limit to kernel heap block size. You might also see if there's some quota on memory usage that you're running up against.
You may want to look into increasing the kernel heap by a few megabytes, or see if there's some limit to kernel heap block size. You might also see if there's some quota on memory usage that you're running up against.
ASKER
Until now only dovidmichel showed some understanding of the problem.
Apart from that,why did I collect only **** on this question? Please read the question and the first answer I got.
If you don't understand it or have no knowledge of the topic, don't show that to me.
And don't comment on this question just because of the 500 points.
;JOOP!
Apart from that,why did I collect only **** on this question? Please read the question and the first answer I got.
If you don't understand it or have no knowledge of the topic, don't show that to me.
And don't comment on this question just because of the 500 points.
;JOOP!
Unless you post the source code of the backup prog nobody is going to be able to help you. For all you have told us at present the first block may have been written with one block size and the next block with a different size.
ASKER
andyalder, you can't read English:
there is no backup and I clearly stated that all 67000 blocks are 512Kb.
Please keep away from this question.
;JOOP!
there is no backup and I clearly stated that all 67000 blocks are 512Kb.
Please keep away from this question.
;JOOP!
Post the source code of the program that wrote the data onto the tape.
ASKER
The program in question contains only calls to libraries I don't have.
Otherwise I had been able to do it myself.
So, how do I code SCSI commands to the tape drive based on the manual data above?
;JOOP!
Otherwise I had been able to do it myself.
So, how do I code SCSI commands to the tape drive based on the manual data above?
;JOOP!
sciuriware,
Sorry but I am not a programmer. I work with SCSI commands to help troubleshoot problems, so although I understand the commands I don't know how to write code.
Perhaps reviewing the manual will be enough to get you going.
http://www.quantum.com/am/service_support/downloads/dlt7000.htm
The DLT 7000 Product Manual is the one that contains the SCSI commands, and is the one I pulled the above data from. Also listed are a couple of documents on installing the drive on HP systems, perhaps there might be something helpful there. Sorry I was not more help. Perhaps there is a parameter in the driver that can be changed to set the block size.
Sorry but I am not a programmer. I work with SCSI commands to help troubleshoot problems, so although I understand the commands I don't know how to write code.
Perhaps reviewing the manual will be enough to get you going.
http://www.quantum.com/am/service_support/downloads/dlt7000.htm
The DLT 7000 Product Manual is the one that contains the SCSI commands, and is the one I pulled the above data from. Also listed are a couple of documents on installing the drive on HP systems, perhaps there might be something helpful there. Sorry I was not more help. Perhaps there is a parameter in the driver that can be changed to set the block size.
ASKER
As I said, that manual is on my desk, and it doesn't help me much.
By now, I know I must practise the right ioctl() call, but today a technician will come and
check if the tape drive can be strapped to that block size.
;JOOP!
By now, I know I must practise the right ioctl() call, but today a technician will come and
check if the tape drive can be strapped to that block size.
;JOOP!
ASKER
Because I must close this question I'm giving the points to dovidmichel.
His solution is surely right but I failed to use it in a program.
Apart from that, there is a problem in HP-UX so when you start SCSI programming to a drive
you're completely on your own and in fact you must write a kind of driver in your application
down from the bottom.
We chose to connect the drive to a Solaris system and then there's no problem.
B.T.W.: LINUX can also handle the blocksize directly.
;JOOP!
His solution is surely right but I failed to use it in a program.
Apart from that, there is a problem in HP-UX so when you start SCSI programming to a drive
you're completely on your own and in fact you must write a kind of driver in your application
down from the bottom.
We chose to connect the drive to a Solaris system and then there's no problem.
B.T.W.: LINUX can also handle the blocksize directly.
;JOOP!
ASKER
P.S.: to dovidmichel:
please post some constructive contribution on:
https://www.experts-exchange.com/questions/20956904/500-point-Question-on-SCSI-programming-behind-link.html
and I'll accept that too.
;JOOP!
please post some constructive contribution on:
https://www.experts-exchange.com/questions/20956904/500-point-Question-on-SCSI-programming-behind-link.html
and I'll accept that too.
;JOOP!
ASKER
1) this has nothing to do with backup; each tape contains up to 67000 blocks of 512Kb..
2) the drive is DLT-7000
3) the OS is HP-UX - 11.11
4) I found that manual on a shelf; I don't have a clue how to use those data in (say) a C program
to set the drive to read - 512Kb - blocks, before I read.
;JOOP!