On Sunday 13 January 2002 03:40 pm, you wrote:
>On Sunday 13 January 2002 12:17 pm, you wrote:
>>On Thursday 10 January 2002 02:31 pm, Thomas Hepper wrote:
>>>To change this will take some time, i think you will hear from
>>> me tomorow,
>>
>>I hadn't heard, my cold isn't any better and the backup
>> schedule restarts tonight for the week. Here is what I've
>> done, and which *appears* to have fixed this problem.
>>
>>1. Download, configure, build and install the 20020111
>> snapshot, which didn't do anything for this problem. This
>> problem being that when show or amcheck reads a tape label, it
>> is not rewinding it for the next pass. The eject reload of a
>> tape change will of course do this, but if amcheck finds a
>> match, the tape was being left at block 64, where a label read
>> by amdump then failed. IMO amdump really should have a rewind
>> in front of its label reads, but I'm not sure where to put
>> that.
>>
>>2. Traceing through the sources, in tape-src/tapeio.c, in the
>>function tapefd_readlabel(), I've added a call to
>>tapefd_rewind(fd);
>>above the
>>tapefd_close(fd); call
>
>The above function is missnamed, it should read: 'tape_rdlabel('
>My bad. See a later post for how I have it now includeing a c/p
>of the whole function as its running *right now*.
>
>>I can now run amtape /config/ show repeatedly, as well as
>> amcheck /config/ repeatedly without errors.
>>
>>The question is: Is this automatic rewind in the
>>tape-src/tapeio.c->tapefd_rdlabel(fd) function going to mess
>> with anything else?
>>
>>IMO, not knowing all the fine points of how amanda is
>> organised, it (to me) doesn't make any sense to do a readlabel
>> without rewinding it for the next readlabel, in most cases it
>> will come as a request from amdump to make sure its writing to
>> the correct tape. So the question then is: will amdump then
>> overwrite the tapes label after it reads it, gets a good one,
>> rewinds to write the fresh one, writes it, rewinds to check it
>> (maybe, I don't know if it does) with the end result being an
>> overwritten label, overwritten by the dumps contents because
>> the tape is NOT going to be left at block 64 after a
>> tapefd_rdlabel(fd) as it was prior to this patch...
>>
>>Thomas, anybody else care to comment here?
Ok, I rebuilt it with the rewind call in front of the rdlabel,
and it fails for a run of amtape /config/ show on the tape
already loaded! I'm looking at the error line
amtape: scanning all 3 slots in tape-changer rack:
slot 0: rewinding tape: Input/output error
slot 1: date 20011222 label DailySet1-02
slot 2: date 20011222 label DailySet1-03
so obviously, amtape must use a different access method to read
the labels. Does this not need to be a common method?
Back to the drawing board I guess. And my former method.
Stupid Q: Why is a rewind returned as an i/o error when its
already rewound, it really should just return success, setting
the bot = TRUE flag if its used.
Watcing the leds on the drive a rewind IS being done by amcheck
before it reads it. Aha! After amcheck is done, finding the tape
it wants, a dd silently returns nothing!
$ dd if=/dev/nst0 count=1
0+0 records in
0+0 records out
$
But repeats are getting compressed data, and finally an advisory
about how to restore in an emergency. Neat.
Now for a run of amtape show, which rewinds the tape, makes no
read attampt at all, and reports an i/o error while rewinding the
tape, but waits about 30 seconds or more to report that on the
first, already loaded tape. And it makes no attempt to rewind
the next tape, nor does it rewind the next one before the read of
the label. So amtape must have its own idea of how to do it.
ammt returns no such errors for repeat runs.
The odd thing, and maybe I'm getting macular degeneration or
something, but I cannot find anyplace in the tapeio.c file where
it actually issues a 'rewind', all these errors would appear to
be coming from bogus slot numbers and such. And this has been
holding me online for several hours now so I'm gonna hit send and
go away.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
98.3+% setiathome rank, not too shabby for a hillbilly
