PDA

View Full Version : Config query re LTO3, SAS HBA and slow speed



zano
March 2nd, 2008, 08:55 PM
I am new to Amanda, so please go easy on me. I have spent hours with the testing and even though the hardware is brand new and on paper should rocket along, it runs VERY slow :-(

I hope an experienced person can cast a glance over my configs and point me in the right direction.

HARDWARE
IBM LTO3 SAS Half Height Tape drive (Part 43W8478)
IBM SAS HOST BUS ADAPTER CONTROLLER (Part 25R8060)
Tapes Sony LTO 400/800GB
[Server disks - 300GB SAS 15K RPM]

########################################
1. One of the first things I did was to amtapetype. See the slow speed!

amtapetype -of /dev/nst0
Writing 512 Mbyte compresseable data: 41 sec
Writing 512 Mbyte uncompresseable data: 42 sec
Estimated time to write 2 * 1024 Mbyte: 168 sec = 0 h 2 min
wrote 11970489 32Kb blocks in 36607 files in 104332 seconds (short write)
wrote 10227761 32Kb blocks in 62747 files in 168570 seconds (short write)
define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression off)"
length 450325 mbytes
filemark 2133 kbytes
speed 2806 kps
}

I ran another test but included the -e and -c switches and the Estimated times look horribly long.

amtapetype -oe 400G -f /dev/nst0 -c
Writing 512 Mbyte compresseable data: 40 sec
Writing 512 Mbyte uncompresseable data: 42 sec
Estimated time to write 2 * 409600 Mbyte: 67200 sec = 18 h 40 min

########################################

2. If it helps any this is some additional info about my tape drive.

mt -f /dev/nst0 status
drive type = Generic SCSI-2 tape
drive status = 1140850688
sense key error = 0
residue count = 0
file number = 0
block number = 1
Tape block size 0 bytes. Density code 0x44 (unknown).
Soft error count since last status=0
General status bits on (1010000):
ONLINE IM_REP_EN

What concerns me is that I have looked around on the web for other LTO3 tape type examples and this is one that I found, the speed is much faster.
Here is an example of tape type definition for LTO-3:
define tapetype LTO3-400-HWC {
comment "LTO Ultrium 3 400/800, compression on"
length 401408 mbytes
filemark 0 kbytes
speed 74343 kps
}

How does one tune or configure the tape drive to run faster to achieve the speed of around 70000kps like the other example config I googled? Also is the "length" differences between my tape type and the example one significant? Can I simply adopt another LTO3 tape type config?

Regards
Gordon Zano

MattM
May 14th, 2008, 06:25 AM
Keys to getting top performance out of an LTO-3 tape drive with amanda:

a) configure the appropriate blocksize for the drive at the OS and amanda level. We use 256K as the blocksize of an LTO-3 drive here.

b) Use good enteprise binaries or compile community edition from source with blocksize option set. Amanda requires that the maximum block size be set when it is compiled. The default zmanda binaries and the default compile settings for community editions to date have not supported large blocksizes, so you'll need to either open a ticket with zmanda to get special binaries or be specific during your own compile.

c) Review the kernel driver options for your scsi controller, and ensure the tape drive is on its own channel. Verify you have a good quality scsi controller.

d) Have a sufficiently powerful server with pci-x or pci-express slots for the drive and tape controllers.

e) configure additional tape buffers/etc in the amanda config and set other amanda options so that you're never writing less than a few GB of data to the drive at any time. We're careful to ensure that our minimum file write is 8GB and we only start writing to tape when we have at least 40GB of data put on the holding disk. Nothing will slow an LTO-3 drive faster than giving it lots of small requests.

f) You do have a very fast logical disk on a raid array setup to be your holding disk right? Amanda needs to be able to read the data in from the holding disk fast enough to continue feeding the tape drive. We have 1TB allocated across 8 10K SAS drives.

g) Turn tape hw compression off. If you are going to be doing any compression or encryption at all on the data, try to do it on the server first while it is writing to the holding disk and make sure you have enough cpu cores/ram to support compress/encrypting multiple streams in parallel.


If you do all the above, you should be able to get a minimum of 68MB/s from the drive. We get 72-75MB/s normally here and I've heard of higher.