LTO-3 read performance issues

LTO-3 read performance issues

[James Pearson]

I have two LTO-3 (QUANTUM ULTRIUM 3) drives attached to a dual Adaptec 
U160 controller (one per SCSI host) on a Dell PE2850 running a RHEL4 
based kernel (2.6.9 based).

I'm trying to read (with tar) LTO-3 tapes written on another system 
(possibly an SGI IRIX box), but I'm getting extremely variable read 
rates - from a few Kb/s to tens of Mb/s - while reading the same tape

After a bit of trial and error, it looks like the tapes have been 
written in variable block mode with a block size of 16Kb

To list the tapes, I need to set the block size to 0 (mt setblk 0) and run:

tar tvfb $TAPE 32

Running strace on the tar process shows that it does a number of 
read()'s then 'sticks' on a read() for a number of seconds, and then 
does a burst of read()'s - the number of reads it does in these bursts 
and the time if waits on a particular read vary.

My guess this is something to do the drive having to repositioning the 
tape between reads and breaking the tape streaming ...

I get the same issue on both drives with different tapes from the same 
source.

I am using the default st module options and not doing anything other 
than using 'mt setblk 0'.

Is there anything I can do to get a decent, sustained read rate from 
these tapes?

Thanks

James Pearson

Re: LTO-3 read performance issues

[Kai Makisara]

On Wed, 7 Nov 2007, James Pearson wrote:

> I have two LTO-3 (QUANTUM ULTRIUM 3) drives attached to a dual Adaptec U160
> controller (one per SCSI host) on a Dell PE2850 running a RHEL4 based kernel
> (2.6.9 based).
> 
> I'm trying to read (with tar) LTO-3 tapes written on another system (possibly
> an SGI IRIX box), but I'm getting extremely variable read rates - from a few
> Kb/s to tens of Mb/s - while reading the same tape
> 
> After a bit of trial and error, it looks like the tapes have been written in
> variable block mode with a block size of 16Kb
> 
> To list the tapes, I need to set the block size to 0 (mt setblk 0) and run:
> 
> tar tvfb $TAPE 32
> 
> Running strace on the tar process shows that it does a number of read()'s then
> 'sticks' on a read() for a number of seconds, and then does a burst of
> read()'s - the number of reads it does in these bursts and the time if waits
> on a particular read vary.
> 
> My guess this is something to do the drive having to repositioning the tape
> between reads and breaking the tape streaming ...
> 
The Quuntum LTO-3 sustained transfer rate is 68 MB/s. Compression does 
increase this. In order to avoid stopping the tape, your system should be 
able to able to process the data continuously at this rate. If this is not 
the case, you can't avoid the stops.

> I get the same issue on both drives with different tapes from the same source.
> 
> I am using the default st module options and not doing anything other than
> using 'mt setblk 0'.
> 
> Is there anything I can do to get a decent, sustained read rate from these
> tapes?
> 
If your system can process the data fast enough and the tape blocks are of 
the same size, you can try using fixed block mode and buffered transfers. 
This allows the driver to use larger SCSI reads. You have to load the st 
module with parameter buffer_kbs=xxx, where xxx is, for instance, 1024 (1 
MB buffer). You also have to disable direct i/o with the module parameter
try_direct_io=0 (otherwise buffered transfers are disabled).

-- 
Kai

Re: LTO-3 read performance issues

[James Pearson]

Kai Makisara wrote:
>>
>>I am using the default st module options and not doing anything other than
>>using 'mt setblk 0'.
>>
>>Is there anything I can do to get a decent, sustained read rate from these
>>tapes?
>>
> 
> If your system can process the data fast enough and the tape blocks are of 
> the same size, you can try using fixed block mode and buffered transfers. 
> This allows the driver to use larger SCSI reads. You have to load the st 
> module with parameter buffer_kbs=xxx, where xxx is, for instance, 1024 (1 
> MB buffer). You also have to disable direct i/o with the module parameter
> try_direct_io=0 (otherwise buffered transfers are disabled).

Thanks, I tried that, but it makes no difference. I also tried 
increasing the buffer_kbs size by doubling it a few times, but that made 
no difference either

I have now found out that the tapes were written on an SGI system - 
using a fixed block device and the default options to tar. However, I 
have to either use 'mt setblk 0' or 'mt setblk 16384' to read anything 
from these tapes.

Just to check that nothing is wrong with my system, I can read an LTO-3 
tape previously written on my system, using the default options to tar 
and the st module - and I get over 40Mb/s on reads, compared with about 
400Kb/s I'm getting with these problematic tapes ...

Is there anything else I can do to read these tapes at a decent speed?

Thanks

James Pearson