On Friday 16 December 2005 11:42, Joshua Baker-LePain wrote:
>On Fri, 16 Dec 2005 at 9:22am, Roy Heimbach wrote
>
>> We have amanda 2.4.5p1 server running under debian linux on a dual
>> opteron that's driving a new overland tape library with an ultrium3
>> drive.  For now, the holding disk is a dedicated local 120 GB
>> drive.
>
>A single drive is going to have an awfully hard time... scratch that.
>  A single drive can *not* feed an lto3 drive as fast as it wants to
> be fed (even if that's the only thing it's trying to do).  I've got
> a 4 disk hardware RAID0 feeding my lto3 drive.

Ahh, I'd argue that point Roy.  Of the two active drives on this 
machine, the main one is a 120GB, and I'm using a 200G as virtual 
disk.  These are on seperate cables of the same on board nforce2 
controller.  As all drives here have dma enabled, the hdparm -tT test 
returns are typically in the 50-60 mb/second rate.  I did have a scsi 
controller in here at one time but the tape died so it was removed.  
But while it was installed, I was able to get 20mg/second transfers to 
another smallish scsi drive hooked up temporarily.  The drive was  
rated as scsi-2-fast, as was the advansys controller.

If this user is only getting 2.5mb/sec, something is wrong with the 
config someplace.  I'd start with the hdparm -Tt /dev/whatever tests 
and see if the dma can be enabled all across the board.

>> There's an amanda 2.4.5p1 client also running under debian linux on
>> another dual opteron that's connected to the amanda server host via
>> a dedicated gig network.  This host is a moderately loaded
>> fileserver with hardware raid.
>>
>> Backing up a 10 GB test partition, we're seeing dumper and taper
>> performance around 2.5 MB/sec, a fraction of what the hardware is
>> capable of.
>
>*snip*
>
>> Any suggestions would be welcome.
>
>Priority one is to figure out where the slowdown is.  Bench the
> hardware RAID with something like bonnie++ and/or tiobench.  Ditto
> for the holding disk.  Use tar to write /dev/zero (using your chosen
> blocksize) to the tape drive.  Then, do a test amdump to holding
> disk.  Amflush that dump.

Good advice as it may pin-point the bottleneck.

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <gene.heskett AT verizononline DOT net> which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.