Arne.Briesenick.ext AT deutsche-boerse DOT com wrote:

I've a problem with amanda (2.4.4p1) on my TapeSet1. It reports an error
when writing a single (19G) file to tape (20G DLT4) on a Quantum DLT4000
without copression.
The most strange thing is, that with the parameters from amtapetype - which
was horrible long time running - that single file does not fit on the tape.
BUT, when I write it explicit by dd if=dumpfile of=/dev/st0 it fits on the
same Tape and there is a real 1G free space at the end of the tape.
So whats the problem with the configuration of amanda?

You didn't tell what OS.  Is it Linux?
In that case it could well be that the following scenario happened:
1. you had first the tapedrive in compressed mode, the default, and
   tested some things using that tape.  Now the first bytes on that
   tape are written in hardware compressed mode.
2. You find out how to disable hardware compression, by using
   the "mt" command, and you disable hw compr with it.
3. Then you label the tape with "amlabel".
4. You run amdump, and the tape overflows...

You may have the impression that after step 2, the drive had
hardware compression off.  This is not completely true in Linux.

When you immediately write to the tape, that is true.
But when you insert a tape, and you read something on it, the drive
automatically adjusts to whatever mode it was written to.

It now happens that amlabel first reads the tape, to verify if there
is already a label on it, and by doing this, the drive adjusts itself
to hardware compression ON.  The label is then written in hardware
compression ON again.
When you run amdump, the same thing happens: amanda verifies the
label, and adjusts the drive to hardware compression ON if needed.
Anything written after it, will be done IN THAT MODE.

To get out of it, you have to disable hardware compression, and then
write to tape WITHOUT reading anything.  That is probably what you did
when trying to write the backup image with "dd".

You can verify this auto-swich to hardware compression with
the command "mt status" before and after reading something
from the tape.

It could just as well be something completely different, e.g. a write
error to tape?  Something in the system logs about this?

PS. about the horrible long time for amtapetype: did you specify
    the "-e 20g" as indicated in the man page?  In that case it would
    take about 5 hours for writing the two passes.

--
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          *
***********************************************************************