Re: No end to problems

2002-08-04 Thread Paul G. Allen

Mitch Collinsworth wrote:
> 
> On Sat, 3 Aug 2002, Paul G. Allen wrote:
> 
> > [root@ista root]# amtape csd show
> > amtape: scanning all 12 slots in tape-changer rack:
> > slot 2: reading label: Input/output error
> > slot 3: reading label: Input/output error
> > slot 4: reading label: Input/output error
> > slot 5: reading label: Input/output error
> > slot 6: reading label: Input/output error
> > slot 7: reading label: Input/output error
> > slot 8: reading label: Input/output error
> > slot 9: reading label: Input/output error
> > slot 10: reading label: Input/output error
> > slot 11: reading label: Input/output error
> > slot 0: reading label: Input/output error
> 
> One common problem is that some changers will return from a tape
> load request before the tape is fully loaded and the tape drive is
> ready to go to work.  In these cases it becomes necessary to add
> some delay time between the tape load command and subsequent tape
> drive use commands, or else do a sleep/retry/timeout sequence.
> 
> Here's what worked for me a few years back with a DLT4000 changer:
> 
> # see if tape drive is ready.  if not, sleep a while and check again
> $remaining = $MAXDELAY;
> while (!open(TAPE,$TAPE) && $remaining > 0) {
> $remaining -= sleep 5;
> }
> if ($remaining <= 0) {
> print "$0 drive $TAPE timed out, not responding\n";
> exit 2;
> }
> 
> I did this just after loading a tape, so any following commands would
> not have to worry about it.  For that changer it took I think close to
> a minute for the drive to become ready.
> 
> More recently, with an AIT2 changer I found the open() call here didn't
> work, so replaced it with a call to mt status and watched the output for
> "General status bits on".
> 

I actually did have to add a delay, but in 2 places. I already had
delays in my script of 15 sec. after each load/unload, and a couple
seconds after arm movements, but I increased the longer delay to 20 sec.
That solved part of the problem, but I was still having issues with
rewinds and reads. Adding some debugging printf()'s in tapeio.c, I found
that the tapefd_open() function was failing. I added a longer delay in
there (changed from 2 to 3 sec.), and now it all seems to be working. I
was able to label all 12 tapes and then run "amtape csd show" with
success. amcheck -s also works now.

Now tomorrow I'll see about performing a test backup (I'm too beat now
after working on this all day).

PGA
-- 
Paul G. Allen
Owner, Sr. Engineer, Security Specialist
Random Logic/Dream Park
www.randomlogic.com



Re: No end to problems

2002-08-04 Thread Mitch Collinsworth


On Sat, 3 Aug 2002, Paul G. Allen wrote:

> [root@ista root]# amtape csd show
> amtape: scanning all 12 slots in tape-changer rack:
> slot 2: reading label: Input/output error
> slot 3: reading label: Input/output error
> slot 4: reading label: Input/output error
> slot 5: reading label: Input/output error
> slot 6: reading label: Input/output error
> slot 7: reading label: Input/output error
> slot 8: reading label: Input/output error
> slot 9: reading label: Input/output error
> slot 10: reading label: Input/output error
> slot 11: reading label: Input/output error
> slot 0: reading label: Input/output error

One common problem is that some changers will return from a tape
load request before the tape is fully loaded and the tape drive is
ready to go to work.  In these cases it becomes necessary to add
some delay time between the tape load command and subsequent tape
drive use commands, or else do a sleep/retry/timeout sequence.

Here's what worked for me a few years back with a DLT4000 changer:

# see if tape drive is ready.  if not, sleep a while and check again
$remaining = $MAXDELAY;
while (!open(TAPE,$TAPE) && $remaining > 0) {
$remaining -= sleep 5;
}
if ($remaining <= 0) {
print "$0 drive $TAPE timed out, not responding\n";
exit 2;
}

I did this just after loading a tape, so any following commands would
not have to worry about it.  For that changer it took I think close to
a minute for the drive to become ready.

More recently, with an AIT2 changer I found the open() call here didn't
work, so replaced it with a call to mt status and watched the output for
"General status bits on".

Whatever works.  :-)

-Mitch