LTO-4 Ultrium 4 1760 SCSI EXT blocksize

[marina cacciagrano]

Hello,
We are using the LTO-4 drive on a Linux system (RHEL4). It is an external 1760, connected to an Adaptec 320SCSi controller.
We are going to write to the LTO-4 tapes using an Autodesk application called onform-2008-sp1.

The application uses tar and mt commands.

It doesn't seem possible to the application to use a blocksize bigger than 64k.
I am wondering what is the impact that this can have on the drive performance.
We did a test, and we managed to get 100GB on the tape in 20min. This makes 5GB/min. Is that what I should expect?
I would like to know the guidelines on the blocksize for this drive.

[Ralf Loehmann_2]

Hello Marina,
I am surprise that you reaches this high performance with a standard tar command. Check the following document, which gives some background for HP highend tape drives and performance troubleshooting: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=lpg50460
The 1760 drive is not in the tables, but it should be close to the LTO 1840, which is the full high LTO-4 drive. The 320SCSI interface should be able get 240MBytes/sec transfered with 2:1 compression theoritical, but the maximum burst rate in the specifications says 180MBytes/sec.
Why I am surprised you might find out after going thru that document. A lot of the testing is most of the time done with not real backup data. There is also a link to tools, which are able to push data out of the memory to a tape, because the expirience is that most of the system standard tools/commands are not reaching the performance really needed to supply enough data to the tapedrive.
Most backup application (not systems tools like tar, dd, dump,...) sending parallel streams of data to a tape device. Backup Performance is depanding on a lot of factors.
One important point here is that most tape drive have a lowest native transfer rate, this data rate is the minimum data rate, which is needed to stream the tape. Streaming means we get enough data to the tape drive, that the drive does not need to stop inbetween. Stopping means extra mechanical wear on tape drive heads and also for the media itself. Not reaching the mimimum speed means I will reduce the life of my drive and media. It might be useful to check, if it is not better to use a backup application for linux instead of system commands.
Check the data under the question "How important is performance" and if you get your performance good between the lowest and the highest native transfer rates you are in good shape. Still remember I talk here about native transfer rate, which is the rate with not compressable data. If the data is highly compressable you might even need to get a much higher throughput to your tape drive, there is also a section and a link in the document about it. I hope the link might be useful.
Regards,
Ralf.

[marina cacciagrano]

Hello Ralf,
Thank you for the link. There is a lot of useful stuff in there.
I must admit that this tape drive, when it works, is quite fast.
With my test, in which we got the 100GB in 20 min, we got an average of 85MB/s which is a bit more than the claimed uncompressed speed of 80MB/s for the 1760 (equivalent to the 960).
I think that it is OK, as we work with image sequences, which are difficoult to compress.
In the link you sent I also discovered that the block size doesn't matter much as:
"The HP Ultrium tape drive manages SCSI blocks in hardware so there is no overhead per block. For these tape drives, the block size does not affect performance."

I also used the tool hptapeperf, downloadable from the link. The performance improved, as I increased the reps parameter, till a max of 119.5MB/s. It is faster that our tests, probably because the transfers are from RAM and probably use higher compression than what we can achieve.


I am still reading the link, learning new things, thanks again.
marina