My main question here would be on the data path. You may be maxing out something in betweeen the two points - though I'd be surprised at 4-5MB/min
Is the drive directly connected to the system? If so, using what kind of SCSI card (specifically, I'm looking to find out the max transfer speed). Any other devices on the same bus? Transferring from tape to disk on the same bus still needs to go via the kernel, so you're effectively halving your max throughput. What other activity is going on on this machine - is the backplane getting saturated to such an extent that data cannot be transferred any faster?
Tape blocksize itself should not be an issue here. The fact that it's reading without error shows that getting data off each block is working fine. If you're looking at changing this, then do it at backup time. Smaller blocksizes for large files will create a small performance hit when writing all the tape marks. Large blocksizes for small files will also create a performance hit since you're writing a whole lot of blank space before the end of the block. At recover time, the blocksize is what's on tape - you're not going to change the way its written at that point.
I'd also suggest getting a scrap tape and sending a 10MB file to it using "time tar cvf..." and recovering using "time tar tvf..." to check the write vs read time (using tvf will still read the entire contents). If there's a big discrepancy here, contact the drive vendor. Use 0m in both cases since you'll get the drive doing the same operations (starting from the beginning, writing/reading, then rewinding).
HTH,
Stuart.
A sysadmin should never cross his fingers in the hope commands will work. Makes for a lot of mistakes while typing.
