Amanda-Users

Re: *Slow* amrestore

2004-03-11 16:03:35
Subject: Re: *Slow* amrestore
From: Jonathan Dill <jfdill AT jfdill DOT com>
To: Joshua Baker-LePain <jlb17 AT duke DOT edu>
Date: Thu, 11 Mar 2004 16:01:06 -0500
Have you taken a look around in /proc/scsi? /proc/scsi/scsi should give you some basic information, and the subdir for your driver should give more details, such as what transfer rate the drive is negotatiated at, for example /proc/scsi/aic7xxx/0 for an Adaptec 2940 series. Perhaps there was a bus problem and the device hooked up at 10 MHz async or something. Reboot and get into the SCSI bios config page and make sure everything in there is kosher. I have even seen a few terminators go bad, so such things are not impossible, even though the drive was writing fine before. Since "dd" is having just as much problems, I would suspect that amanda is not the problem per se. Could be kernel, could be hardware, could be the tape cartridge, could be some stupid, proprietary Sony thing, dip switch settings on the drive, hardware compression settings.

In some cases, I have taken tape drives and hooked them up to a Windows box so I could run proprietary diagnostics, take a look at the tape drive's internal logs, update the drive firmware. I think the weirdest stuff was using a 9600 bps null modem serial terminal connection to connect to the embedded console on an Exabyte 10h library, very strange set up. I have also pulled out SCSI cards and put them on a Windows box to check out the SCSI BIOS and load new firmware.

Run a cleaning tape through just in case--with some drives, I had the problem of drives actually needing cleaning more frequently than the drives thought they needed it. Exabyte Eliant drives were notorious for that--I would run into these problems where I had to run a cleaning tape through 5-6 times in a row (even though the drive said it didn't need cleaning) and then finally it was fine, but in those cases, I was also seeing read and/or write errors. The Eliants just based cleaning on hours of read/write time, which turned out not to be often enough, so crud would accumulate over time--no doubt because amanda was streaming so efficiently that the drive was actually processing more length of tape than ordinarily anticipated :-)

--jonathan

<Prev in Thread] Current Thread [Next in Thread>