|
Re: Exabyte VXA-2 Packet-Loader and chg-zd-mtx nagging problem
2005-02-24 07:04:53
Hi!
/usr/sbin/amdump new && /bin/mt -f /dev/nst1 offline && /usr/sbin/amtape
new slot next
Amanda changes the tapes as needed, i. e. you don´t need to call amtape
(and mt) for that.
When testing this manually from the console, I receive the following
error message when running the amtape command:
amtape new slot next
amtape: could not load slot 7: mtx: Request Sense: Long Report=yes
However, after a long wait, it in fact DOES perform this command
correctly and has the next tape loaded as it should.
This is my only nagging bug. What is causing this and how can I fix
it ?
Hm, from one of your previous posts I´ve seen the SCSI-errors your
getting in the syslog. Are there still such errors being reported?
I would guess that there´s a problem with the SCSI controller leading to
very long timeouts before responses to mtx commands. Thus, mtx times out
and gives you the above message, but the command is finally performed
after that long wait during which the SCSI controller is being reset and
such by the driver. The command has been wating in the queue for the
SCSI devices to become ready, and then gets executed.
Unless you fix that, amanda might be unable to change tapes
automatically because it might have likewise problems with unexpected
delays in SCSI command-execution (especially when using mtx on the low
level side to do the changes). --- There is sometimes combinations of
computers/mainboards and (SCSI-)cards that just don´t work.
BTW, the VXA-drive can be used in native mode. Afair, docs only say that
the identification strings the drive will answer inquiry commands with
can be changed by using different modes, and I don´t think that the
modes will change anything else beyond that for the drive uses standard
SCSI commands. Does anybody know if this is true?
GH
|
|
|
