DLT 4000s - works fine then slows to a crawl

[Guy Humphreys]

morning all,

here is one for the long serving members of this fine forum.

I have just replaced a DLT4000s drive onto one of our servers, it is a TTI model and I set the dip switches to the same config as the previous drive, i.e.

1,2,3,4,5 set to ON
6,7,8,9 set to OFF
10,11,12 set to give SCSI ID 4

this should give me a drive without any emulation/running in native mode. I say should as I have no manual and can't find one on the internet as the drive is so old and it looks like TTI have gone out of business.

my problem is that when I do a fbackup it works fine for between 1500 and 2500 files and then it slows to a complete crawl. so slow in fact that it takes over 24 hours for the backup to complete and it gets overwritten by the next days job. It doesn't matter which files I try to backup, any directory I try the same thing happens.

my fbackup config file is this:

blocksperrecord 512
records 64
checkpointfreq 1024
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200

has anyone got any ideas on how to fix this problem.

thanks as ever
Guy

[Steven E. Protter]

Shalom Guy,

more data.

ioscan

Its important that the tape drive have a SCSI card all to itself and that no other devices on the system conflict with it.

Its possible there is a hardware flaw with the device.

The system needs to be checked and note that if you want to make up files in a directory with say 1,000,000 files, the operation will be painfully slow because the ls command needed to get a file list will run very,very long. This should be looked into.

SEP

[Guy Humphreys]

Shalom SEP,

attached is an ioscan -fn of the box in question

I have not ruled out hardware prob, i just want to check my fbackup is configged OK before things get drastic and I have to down the box, it's totally non hot-pluggable and I hate downing servers!

cheers
Guy

[Bill Hassell]

Your config file is way off for a streaming tape drive. Use this instead:

blocksperrecord 4096
records 64
checkpointfreq 4096
readerprocesses 6
maxretries 5
retrylimit 5000000
maxvoluses 200
filesperfsm 2000

You want to minimize the number of data starvation periods and overhead features like checkpoints and setmarks. This should help.

[Michael Steele_2]

If its taking that long then please paste in the Logtool report whick will give a range of time in hours or days and the number of errors generated by each device. tape, disk, scsi controller, etc.

STM > TOOLS > UTILITY > RUN > LOGTOOL > FILE > VIEW > RAW SUMMARY

This link had a fbackup.config from patrick walleck for you to compare to:

http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=941045

[Guy Humphreys]

Bill, I tried your suggestion and got this error message:

SCADASP /etc $fbackup -v -c /etc/fbackup_config -g /etc/test.graf -f /dev/rmt/2m
fbackup(1421): no history is available for graph file /etc/test.graf (below level 0)
fbackup(1004): session begins on Tue Jun 13 14:31:08 2006
fbackup(1009): cannnot get the specified shared memory segment


so I dropped the blocksperrecord down to 2048, the fbackup ran but again slowed down at approx 3500 files

I tweaked blocksperrecord up to 3072 and got a very similar response

I am thinking it may be hardware replacement time, the annoying thing is the drive is new (to us) and from a (until now) reputable supplier.

just out of curiosity how much slower is HP7840 (or whatever number it is) emulation mode than native?? I could switch it to this if this would give me more reliability, I only have a couple of gig to backup so speed is not intensely critical

cheers
Guy

[Bill Hassell]

fbackup will need a fair amount of shared memory but I suspect you never changed the default value of 67 megs. Go into SAM and change shmmax to 900 megs and let the kernel regen and reboot. Then fbackup will be able to get the amount of RAM needed.

I don't know what an HP 7840 might be. What hardware do you have now?

[Guy Humphreys]

Bill, I got the model number a bit out, the emulation mode is for a HP7980 - an old reel to reel device I believe.

Sure, it would be slow, but like I say as long as it backs up ~2GB in 8 hours I don't care.

shmmax is at 256MB at the moment - a reboot is not an option for us, but next time we do I'll beef it up to 900 as you suggest.

I have found that tar performs better than fbackup with this drive, so unless anyone has any better thoughts I will put gtar on the box (I need to exclude some directories) and use multiple tars to get each lvm one at a time so it should not 'overload' the drive. It's far from ideal but is only a stop gap solution until we migrate the box later in the summer.

cheers
Guy