On Thursday 20 May 2004 12:35, David Wolfskill wrote:
And I took this back to the list based on the more eyeballs theory,
David.
>>amcheck-server: slot 2: date 20040520 label DailySet1-03 (active
>> tape) amcheck-server: slot 3: date 20040426 label DailySet1-05
>> (active tape) amcheck-server: slot 0: date 20040519 label
>> DailySet1-02 (active tape) amcheck-server: slot 1: date 20040520
>> label DailySet1-03 (active tape) ERROR: label DailySet1-04 or new
>> tape not found in rack
>> (expecting tape DailySet1-04 or a new tape)
>>
>>Ohkay, not noticing that its claiming tape 3 is in 2 slots, I
>> reloaded the magazine and issued another call to amcheck, which of
>> course returns:
>
>If you get can get that sort of response again, try at least one of:
>
>* Unloading & reloading the magazine, then re-try the operation (to
> see if it's consistent).
>
>* Unloading the magazine, changing the order of the tapes in the
> magazine, then re-try the operation (to see if maybe something is
> lying to you about which slot it's using.
It just did it again, David. And I'm getting more and more convinced
there is a bug of some kind that only shows up if runtapes>1, and it
needs to change the tape in midrun.
>From the amdump run:
These dumps were to tape DailySet1-05.
*** A TAPE ERROR OCCURRED: [[label DailySet1-06 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 2 tapes Amanda expects to used are: DailySet1-06,
DailySet1-07.
FAILURE AND STRANGE DUMP SUMMARY:
coyote /root lev 2 FAILED [out of tape]
DailySet1-06 is in fact the last tape in the magazine as will be shown
below when I run amcheck by hand for the second time.
Then my wrapper script calls another script that appends all the
indices and configs to the tape also failed:
/amanda/bak-indices-configs: line 20: At block 114157.: syntax error
in expression (error token is "block 114157.")
which is not an error I've seen before, and that block location
indicates that there should be room on the tape for the extra stuff,
and when I check that scripts line 20, that has nothing to do with
the above output. The only place where that above, and incompletely
stripped variable is used is in lines 72-76. The word 'block' should
have been stripped by this statement:
LOCATION=`mt -f /dev/nst0 tell | tr -d '[a-zA .]'`
Then later, anyplace a dd operation was to write to the tape:
/dev/nst0: Input/output error
DailySet1-05 was not written to
And later, my wrapper calls amcheck -m to make sure the correct next
tape is available:
amcheck-server: slot 3: date 20040521 label DailySet1-05 (active tape)
amcheck-server: slot 0: date 20040520 label DailySet1-03 (active tape)
amcheck-server: slot 1: date 20040520 label DailySet1-04 (active tape)
amcheck-server: slot 2: date 20040521 label DailySet1-05 (active tape)
ERROR: label DailySet1-06 or new tape not found in rack
(expecting tape DailySet1-06 or a new tape)
But another run of amcheck by hand, without touching the magazine,
give this:
amcheck-server: slot 2: tape_rdlabel: tape open: /dev/nst0:
Input/output error
amcheck-server: slot 3: date 20040427 label DailySet1-06 (exact label
match)
The first line is the error caused by my not manually issueing an 'mt
-f /dev/nst0 rewind' before calling amcheck. The previous run left
the tape sitting at block 1, and because amanda(amcheck(chg-scsi))
cannot rewind a tape, the label cannot be found and read. This is
turning into a major PITA.
So my instant opinion is that it didn't advance the tape to slot 3,
but thought it had since it found the tape that was actually in slot
2 in what it *thought* was slot 3. And amdump couldn't finish the
job, either because the rewind call is broken in chg-scsi (which it
has been for about a year, ISTR seeing a note in the st docs
someplace indicating that the rewind call had been "fixed" for
consistent syntax usage) and it couldn't id the next tape, so it left
what should have been written to tape 2 of the runtapes=2 option in
the holding disk.
I'm about through screwing with this broken chg-scsi utility and its
broken rewind call. Can anyone testify that chg-mtx might be any
more reliable on a Seagate 4586 changer? Lately I've been spending
at least an hour a day chaseing after backup errors.
FWIW, ammt doesn't have any problems rewinding the tape. After the
second run of amcheck shown above:
[amanda@coyote amanda]$ mt -f /dev/nst0 tell
At block 1.
[amanda@coyote amanda]$ ammt -f /dev/nst0 rewind
[amanda@coyote amanda]$ mt -f /dev/nst0 tell
At block 0.
[amanda@coyote amanda]$
I've looked at the chg-scsi srcs myself and cannot seem to locate
where the rewind call is used, its apparently using only ioctl stuffs
that look like so much swahili to me.
>
>Peace,
>david
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
|
