LTO-2 tape device is very slow?

[J. Epperson]

Ed's probably on point--slow DLTs and LTOs are usually repositioning 
because they're not fed well enough to stream.  Adjusting driver parms 
can help, so can various forms of buffering.  Also see "star" 
manpages--it was written to replace tar, with streaming drives in mind. 
  See the fifo option in particular.

Ed K. wrote:

> On Tue, 14 Dec 2004, Tom Haws wrote:
> 
>> I'm having problems adding an Exabyte Magnum LTO-2 tape device to my 
>> RHL 9 machine.  I know that's a different OS, so thius question should 
>> go in the shrike lists, but it's close enough to Fedora that I thought 
>> I might get some answers here, and the shrike lists are just about 
>> dead now.  Red Hat announced the end of RHL 9 2 months after I 
>> installed a production server on it...  arrrghh...
>>
>> Anyway, after I add the device, it shows up fine in /proc/scsi/sci, 
>> and I can write to it, but it is extremely slow.  I got about 30MB 
>> written in 5 minutes!  Has anyone else had any experience with LTO-2 
>> devices on Fedora or RHL 9 systems, and is there anything I can do to 
>> recreate device files or anything to speed it up?
>>
>> Also, do you know if I do a "mknod -m 666 /dev/st0 c 9 0" with the 
>> tape drive hooked up, does it do anything different than if there 
>> wasn't one installed? Like read the status bits on the drive to tell 
>> what it's capabilities are?
>>
> 
> Tom,
> 
> I have a similar problem on a DLT-1 on a FC1 computer, and had problems 
> with speed until I found the proper way to write to the tape. Here are 
> the commands to prime the tape:
> 
> modprobe st buffer_kbs=1024 max_buffers=128 max_sg_segs=128 blocking_open=1
> mt setblk $[64*1024]
> 
> #test
> tar -cf - .|mbuffer -s $[64*1024]  > /dev/tape
> mbuffer -s $[64*1024] < /dev/tape > /dev/null
> 
> You can find mbuffer at:
> http://directory.fsf.org/All_Packages_in_Directory/mbuffer.html
> 
> ed
>