Re: *Slow* amrestore
2004-03-11 16:03:35
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
|
|
|