> Date: Fri, 24 May 2002 15:23:02 +0200
> (=?ISO-8859-1?Q?V=E4steuropa=2C_sommartid?=)
> From: Ulrik Sandberg <[EMAIL PROTECTED]>
> Subject: RE: Reducing the amount of output from amverify
>
> On Fri, 24 May 2002, C R Ritson wrote:
>
> > I use (as a cron job) for both the backup and its following amverify
> > run:-
> >
> > /usr/local/amanda/current/sbin/amdump ncl && \
> > /usr/local/amanda/current/sbin/amverify ncl \
> > >/tmp/amanda/amverify.debug 2>&1
>
> What happens if you eject and then forget to switch tapes? Like in:
>
> amdump && amverify ; mt -f /dev/rmt/1n offline
>
> I think amverify prompts for a tape and then just sits there.
> This might
> affect the following amdump in a bad way. Processes already
> running and
> such.
>
> What happens if you DON'T eject and then forget to switch tapes?
>
> Will amverify find the wrong label and then exit with a failure?
I am using a tape changer, and a very cautious approach in cron (I have
split the longer crontab line for readability):-
02 11,16 * * 1-5 /usr/local/amanda/current/sbin/amcheck -ms ncl
50 23 * * 1-5 /usr/local/amanda/current/sbin/amdump ncl && \
/usr/local/amanda/current/sbin/amverify ncl \
>/tmp/amanda/amverify.debug 2>&1
Ulrik is right, there could be a problem here, but even during a
holiday, the subsequent amcheck runs will attempt to do the right thing
for us. The problem would arise if an amdump run somehow left a tape
offline but still in the drive, not back in its slot in the tape
changer. For us, I think it would take a hardware fault (not just a tape
error) to cause that. In that state, amverify will get into a loop, made
worse by the fact that our "mt -f /dev/nst0 status" (used by amverify to
see if the tape is ready) returns success (0) when the tape is in the
drive housing, but not online. The subsequent rewind attempt gets into
an infinite loop returning a tape error. In this state, our first
attempt to run amcheck will get us a race condition, with the amverify
running to completion eventually, although it may well not examine that
tape most recently written. The second amcheck run will then load the
correct next tape if it is in the changer.
It looks a little as if amverify could do with checking over, but first,
I will need to switch from using a non-standard tape changer glue script
to chg-zd-mtx, then if I can still cause problems I will try and look
into them.
Chris Ritson.
