[KLUG Members] why is my tape drive so slow???

[Adam Williams]

> >>> standbys like dump and tar.  The problem is neither of these seem to be 
> >>> able to use the tape efficiently.  It keeps backing up, 
> >It is "shoe-shining".
> >>> I assume because 
> >>> the system isn't feeding it data fast enough.  
> >Most likely.
> >>> Here's the hardware 
> >>> details:  Pentium 2 350, 192 Megs memory.  Drive system is an LVM mirror 
> >>> of fairly new 60 gig IDE hard drives.  tape is a Seagate DDS-3 SCSI 
> >>> (although I've had the same problem with an HP Colorado TR-4) controlled 
> >>> by an Adaptec 2940UW.  Redhat Linux 8.0, standard Kernel.  Since I don't 
> >>> run XWindows, shouldn't this machine be more than capable of keeping up 
> >>> with the tape drive?
> >If you do a "mt -f /dev/st0 status" what does it say?  Are you passing
> >tar any blocking factors?
> I was wondering if there was a way to force larger buffers or something, 
> but no.  Don't know how to pass tar a blocking factor.  

By default tar uses a 20x512 byte blocking factor; that is 20 units of
512 bytes.  You can change this with -b {int}.  The result will be a
block size of 20 x {int}.  On certain hardware sliding this value around
often helps - fewer blocks per block <?> means a more constant stream,
if your machine is having problems stuffing the bus.  Usually helps to
go UP, but never higher than half your ST buffer size, usually one
quarter.

A best guess is that a "b" value of 64 will give you the biggest bang
for your, well...., keystroke.  Darn free software destroys all the old
metaphors.

I assume your loading the "st" kernel module and using your tape drive
through that. If you compiled a monolithic kernel your screwed { and
that is a dumb idea for OH SO MANY reasons }.

Try -
modprobe -r st
modprobe st buffer_kbs=128

You should see a line in dmesg like -

st: Unloaded.
st: Version 20030406, bufsize 131072, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi1, channel 0, id 4, lun 0

See "bufsize 131072".  By default the st module creates a 32k buffer,
which is just way to small.  On some boxes (typically the black rack
mounted beauties that say I-B-M on them) I've seen performance climb up
through a 256k buffer.  White box crap PC-wanna-be-a-server boxes seem
to do best at around 128k;  although you should of course test your own
hardware.

> In fact, I'm not even sure what it means! 

The size of the chunk of data to accumulate before chucking it out to
the device.

> ;-\  Anyway, here's the output from mt -f 
> /dev/st0 status:
> [root@moore root]# mt -f /dev/st0 status
> SCSI 2 tape drive:
> File number=0, block number=0, partition=0.
> Tape block size 0 bytes. Density code 0x25 (DDS-3).
> Soft error count since last status=0
> General status bits on (41010000):
>  BOT ONLINE IM_REP_EN

You can try moving the block size around; "mt -f /dev/st0 setblk 4096",
etc...  And go back to the default with  "mt -f /dev/st0 setblk 0". 
Depending on your firmware this may or may not make a difference.

> How would bus errors show themselves?  

They'd appear in dmesg.

> I don't think that's the problem, 
> though, because the few times I've been able to explain to Bacula what 
> want it to do it runs the tape without "shoe-shining".  Shoe-shining 
> being my word of the day...

it is a good word.  But much more appriate back in the day of
reel-to-reel, when tape drives made alot more noise.