[CLUE-Tech] Slow DLT performance

[Casagrande, Steve]

While it's been years since I've done tape stuff, I do recall that if you
can't feed the tape drive with enough data to keep it streaming, it will
stop, rewind, and start again, which absolutely kills throughput.

Perhaps you could write a small program to dump random data to the drive,
and measure throughput?  This would take the disks out of the equation.
(Maybe there's a conflict between the RAID controller and the tape
controller...)

Good luck,

Steve Casagrande
Steve.Casagrande at echostar.com


-----Original Message-----
From: Dan Harris [mailto:coronadh at coronasolutions.com] 
Sent: Wednesday, October 22, 2003 10:20 AM
To: clue-tech at clue.denver.co.us
Subject: [CLUE-Tech] Slow DLT performance


I was running out of space on my Quantum DLT4000 so I upgraded to a 
DLT8000.  It was a long, arduous journey.. For the archives, I'll 
mention that this drive will NOT work unless it is the only device on 
the SCSI bus..

Two nights ago I ran my first backup onto it.  The script runs 'tar' to 
back up local files which total about 30 gigs uncompressed.

For some reason, it's taking 24 HOURS to perform the backup!  The drive 
is rated at 6 MB/s uncompressed and 12 MB/s with hardware  2:1 
compression.  According to my calculations, that should take about 40 
minutes to back up all 30 gigs.
So, I'm nowhere NEAR that speed and I'm trying to figure out why.  The 
server is a single 2.4GHz Pentium 4 with an Intel SCR42U RAID-5 Ultra 
160 RAID with 64 megs of disk cache and an Adaptec 29160 64-bit PCI 
(running in 32-bit slot) card hosting the tape device.  This isn't the 
fastest server in the world, but the disk I/O seems more than up to the 
task.  The RAID perfomance is outstanding and I've never had any 
problems with speed, only writing to the tape.

The old DLT4000 was running on the RAID controller and was taking about 
18 hours to run the backup, which I blindly assumed was normal until I 
recently went looking at the rated throughput.  So, assuming this isn't 
normal, I guess the problem doesn't follow the controller or the 
drive..  Maybe this is a configuration or kernel issue?
I've tried turning on and off compression on the drive and it doesn't 
seem to make any significant difference in the speed.  I called Quantum 
and they won't help me because it's not Red Hat Linux (it's Debian/woody 
with 2.4.22 custom kernel) and the drive passed all of their tests 
(which of course only run on Windows).  There's always activity on that 
server but nothing really I/O intensive during these hours.

Has anyone seen this before or have an idea of how else to troubleshoot 
this?

Thanks,
Dan

_______________________________________________
CLUE-Tech mailing list
Post messages to: CLUE-Tech at clue.denver.co.us
Unsubscribe or manage your options:
http://clue.denver.co.us/mailman/listinfo/clue-tech