Amanda-Users

Re: problem labelling tapes

2003-10-23 06:23:06
Subject: Re: problem labelling tapes
From: Paul Bijnens <paul.bijnens AT xplanation DOT com>
To: Tony <td_miles AT yahoo DOT com>
Date: Thu, 23 Oct 2003 12:16:08 +0200
Tony wrote:

As an aside, I did manage to work out the stinit stuff and the
drive is no longer using hardware compression. I did another
tapetype and got the following:
...
which is a lot more like what it should be.


Any suggestions on why it is not recognising the label ?

Now that you have a correct stinit.def, the stuff should work better.
But there is still one gotcha.  When you insert a tape that was
written with other settings, and you READ something on that tape,
the drive adjusts itself automatically to the settings of the tape.
This is very convenient to read a tape (you don't have to be guess
what the settings were), but when you write subsequently to that tape,
the drive does it with these settings, and those that you specified
in stinit.def.

I've been hit (and many people on this list) a few times with the
compression status.  You label a few tapes (or all tapes in my case)
with compression on (because you didn't notice, or by accident).
Later you find out about stinit.def and how to disable compression
with "mt" etc and you think you're safe now.  But when amanda verifies
the label, it automatically resets the drive to "compression on" for
those tapes. Writing this tape is silently done with compression
on, resulting is about 20-30% capacity loss.  Many people don't even
notice, until they hit EOT prematurely (and sometimes think it is a
bad tape).

To correct this behaviour, you have to set the correct parameters
in the drive (in stinit.def and/or using mt) and then write some data
to the tape WITHOUT reading it.
You can't use amlabel for this, because it first verifies the tape in
the drive, to check for an already existing amanda label.
The program amtapetype does work to erase a tape.  You don't need
to run it completely to the end; using the new "-c" option is
sufficient and takes only a few minutes for each tape. Something like:

        amtapetype -c -f /dev/st0

And then run amlabel again.


If I continually run amcheck, about maybe 5% of the time I will
get the response "Tape daily01fri label ok", to indicate that it
was actually able to read the label on the tape. This is VERY
strange !

The above does not explain why you get in about 5% of the cases
a correct labelcheck.  There is still "something else"...  Maybe
even a hardware problem.  (But why does it consistently shows 9 bytes
of the label is strange in that case too.)

--
Paul Bijnens, Xplanation                            Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit,  ZZ, :q, :q!,  M-Z, ^X^C,  logoff, logout, close, bye,  /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* kill -9 1,  Alt-F4,  Ctrl-Alt-Del,  AltGr-NumLock,  Stop-A,  ...    *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************