Resolved: LTO-2 tape device is very slow?

Tom Haws trh at timberline.ca
Wed Dec 15 17:48:31 UTC 2004


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. 
>>
>> Anyway, after I add the device, it shows up fine in /proc/scsi/scsi, 
>> 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?
>
> 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
>
Thanks for your suggestions, Ed.  I didn't actually try your solution 
above, but thanks to your reply and C. Linus Hick's reply, it got me 
thinking about blocksize, and that's what proved to be the solution.

I had originally looked at Exabyte's ltoTool and libTool as per C. Linus 
Hick's reply, but at first glance thought they were just for flashing 
the firmware.  Get them here:  
http://www.exabyte.com/support/online/downloads/downloads.cfm?prod_id=581

Actually, libTool is pretty cool- like mtx, you can move media from slot 
to drive etc.  And ltoTool offers a test function.  It wrote and read 
back 4GB in only a few minutes using /dev/st0, so I knew my tape device 
was ok.

Then I noticed that mt reports that the tape block size is 32768 bytes:

mt -t /dev/nst0 status
SCSI 2 tape drive:
File number=18, block number=0, partition=0.
Tape block size 32768 bytes. Density code 0x42 (no translation).
Soft error count since last status=0
General status bits on (81010000):
 EOF ONLINE IM_REP_EN

When I used tar and dump with a "-b 32" or "-b 64" to manually set the 
block size, it just flew.  My transfer rate went from 10kb/s with the 
default 10k block size, to 11000kb/s with either 32k or 64k block 
sizes.  Much more like the performance I was expecting...

This is good enough to get me using the device right now, but I'd still 
like to try the mbuffer solution above.  I would try "star" as suggested 
by J. Epperson, but it does not allow a single file to span tapes yet, 
and I need that.

Thanks, and keep posting!
-Tom

-- 
_______________________________________________________________________
Tom Haws               Manager, Systems Administration
trh at timberline.ca      Timberline Forest Inventory Consultants
Tel: (250) 562-2628    1579 9th Ave, Prince George, B.C. Canada V2L 3R8
Fax: (250) 562-6942    http://www.timberline.ca
_______________________________________________________________________




More information about the fedora-list mailing list