|
Re: getting "tape not found" errors
2006-06-17 11:30:50
Jon LaBadie wrote:
On Sat, Jun 17, 2006 at 12:11:26PM +0100, Rodrigo Ventura wrote:
Hi all,
Occasionaly I get the following errors after amdump:
*** A TAPE ERROR OCCURRED: [label ISR006 or new tape not found in rack].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: ISR006.
which is simply not true, since
$ amtape ISR label ISR006
amtape: scanning for tape with label ISR006
amtape: slot 3: date 20060615 label ISR004 (wrong tape)
amtape: slot 4: date 20060616 label ISR005 (wrong tape)
amtape: slot 5: date 20060612 label ISR006 (exact label match)
amtape: label ISR006 is now loaded.
works just fine.
No certainty, just possibilities based on what I've observed
with my DDS3 changer and tapes:
- failing tape that is still sort of ok
- tape heads needing cleaning
- changer and/or other scripts needing delays to let actions
complete because the hardware driver sometimes returns with
success before an action is completed
This has the waddle and quack of the same duck I used to fight with when
using DDS2 tapes in a Seagate 4586n changer.
I was then using chg-scsi to run the changer, and I came to the
conclusion, even straced it, that chg-scsi was not capable of issueing a
rewind command to the drive, and that chg-scsi then left the tape
sitting at block 1 when it should have left it at block 0. The next
time it ran, it wouldn't find that ape in the drive, and would then
cycle thru the rest of the magazine looking for, and failing to find it.
The next time amcheck ran, it advanced that tape back into the drive
and found it. Next time it would fail etc etc, working every other
time. As you can imagine, this put a lot of wear and tear on the
cchanger, contributing to their early demise in my environment and
causing me to go to virtual tapes about 2 years ago now.
Conversely, if it found it, then amdump couldn't, cycleing thru the
magazine. A new run of amdump would then cycle that tape back in and
find it just fine, and amdump itself could rewind the tape and apply the
new label header with that date & run the backup just fine.
The problem was that chg-scsi's only way to rewind a tape was to eject
it, at which point the drive rewound it as part of the ejection. And
neither chg-scsi, nor amdump, presumably using chg-scsi as the
interface, would rewind the tape before the initial label check.
I posted about it at the time, but I guess everyone just figured I had
duff changers because I've never seen a fix for chg-scsi checked into
the ChangeLog. I looked at chg-scsi myself, thinking I might be able to
fix it, but came to the conclusion I wasn't smart enough to fix that
bowl of spagetti. The last person I know of that worked on chg-scsi, a
german gent, hasn't been heard from since about 2002 on this list.
Thomas Hepper ISTR.
--
Cheers, Gene
|
|
|
